Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rpi-4.19-rt #2943

Open
antonellocaroli opened this issue Apr 26, 2019 · 71 comments

Comments

@antonellocaroli
Copy link

@antonellocaroli antonellocaroli commented Apr 26, 2019

there's going to be a 4.19 real time version?

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented Apr 26, 2019

I hope so. We are currently relying on a volunteer - Tiejun Chen - to maintain the branch, and other commitments have meant that he hasn't had time recently.

@paul-1

This comment has been minimized.

Copy link

@paul-1 paul-1 commented Apr 30, 2019

The RT patches apply cleanly to the 4.19.y branch. Been running pretty solid.

@vanfanel

This comment has been minimized.

Copy link

@vanfanel vanfanel commented May 2, 2019

@paul-1 : I am trying to apply the RT patch to 4.19.y branch, too.
Looking at the contents of the patch TAR in , I see there is a list of patches available:

0009-kthread-convert-worker-lock-to-raw-spinlock.patch
0012-arm-Convert-arm-boot_lock-to-raw.patch
0023-EXP-rcu-Revert-expedited-GP-parallelization-cleverne.patch
0028-sched-migrate_disable-Add-export_symbol_gpl-for-__mi.patch
0032-signal-Revert-ptrace-preempt-magic.patch
0036-rt-Provide-PREEMPT_RT_BASE-config-switch.patch
0052-x86-Use-generic-rwsem_spinlocks-on-rt.patch
0059-preempt-Provide-preempt_-_-no-rt-variants.patch
0061-rt-Add-local-irq-locks.patch
0066-buffer_head-Replace-bh_uptodate_lock-for-rt.patch
0067-fs-jbd-jbd2-Make-state-lock-and-journal-head-lock-rt.patch
0070-genirq-Disable-irqpoll-on-rt.patch
0076-mm-page_alloc-rt-friendly-per-cpu-pages.patch
0077-mm-swap-Convert-to-percpu-locked.patch
0098-time-hrtimer-avoid-schedule_work-with-interrupts-dis.patch
0099-hrtimer-consolidate-hrtimer_init-hrtimer_init_sleepe.patch
0100-hrtimers-Prepare-full-preemption.patch
0101-hrtimer-by-timers-by-default-into-the-softirq-contex.patch
0102-sched-fair-Make-the-hrtimers-non-hard-again.patch
0103-hrtimer-Move-schedule_work-call-to-helper-thread.patch
0104-hrtimer-move-state-change-before-hrtimer_cancel-in-d.patch
0105-posix-timers-Thread-posix-cpu-timers-on-rt.patch
0115-rt-Increase-decrease-the-nr-of-migratory-tasks-when-.patch
0128-rtmutex-trylock-is-okay-on-RT.patch
0130-rtmutex-Handle-the-various-new-futex-race-conditions.patch
0135-locking-locktorture-Do-NOT-include-rwlock.h-directly.patch
0136-rtmutex-Add-rtmutex_lock_killable.patch
0137-rtmutex-Make-lock_killable-work.patch
0139-rtmutex-Avoid-include-hell.patch
0141-rtmutex-Provide-rt_mutex_slowlock_locked.patch
0142-rtmutex-export-lockdep-less-version-of-rt_mutex-s-lo.patch
0143-rtmutex-add-sleeping-lock-implementation.patch
0144-rtmutex-add-mutex-implementation-based-on-rtmutex.patch
0145-rtmutex-add-rwsem-implementation-based-on-rtmutex.patch
0146-rtmutex-add-rwlock-implementation-based-on-rtmutex.patch
0147-rtmutex-rwlock-preserve-state-like-a-sleeping-lock.patch
0148-rtmutex-wire-up-RT-s-locking.patch
0149-rtmutex-add-ww_mutex-addon-for-mutex-rt.patch
0151-locking-rt-mutex-fix-deadlock-in-device-mapper-block.patch
0152-locking-rt-mutex-Flush-block-plug-on-__down_read.patch
0153-locking-rtmutex-re-init-the-wait_lock-in-rt_mutex_in.patch
0155-rtmutex-annotate-sleeping-lock-context.patch
0168-rt-Improve-the-serial-console-PASS_LIMIT.patch
0183-rt-Introduce-cpu_chill.patch
0184-hrtimer-Don-t-lose-state-in-cpu_chill.patch
0185-hrtimer-cpu_chill-save-task-state-in-saved_state.patch
0196-seqlock-Prevent-rt-starvation.patch
0197-sunrpc-Make-svc_xprt_do_enqueue-use-get_cpu_light.patch
0207-printk-Make-rt-aware.patch
0214-kgdb-serial-Short-term-workaround.patch
0216-mm-rt-kmap_atomic-scheduling.patch
0219-arm-Enable-highmem-for-rt.patch
0227-x86-stackprotector-Avoid-random-pool-on-rt.patch
0228-random-Make-it-work-on-rt.patch
0240-sched-Add-support-for-lazy-preemption.patch
0242-x86-Support-for-lazy-preemption.patch
0245-arm-Add-support-for-lazy-preemption.patch
0246-powerpc-Add-support-for-lazy-preemption.patch
0247-arch-arm64-Add-lazy-preempt-support.patch
0249-drivers-block-zram-Replace-bit-spinlocks-with-rtmute.patch
0254-drm-radeon-i915-Use-preempt_disable-enable_rt-where-.patch
0259-cpuset-Convert-callback_lock-to-raw_spinlock_t.patch
0262-signals-Allow-rt-tasks-to-cache-one-sigqueue-struct.patch
0264-Linux-4.19.37-rt19-REBASE.patch

What set of patches do you apply to get a stable RT kernel on the Pi?

@antonellocaroli

This comment has been minimized.

Copy link
Author

@antonellocaroli antonellocaroli commented May 2, 2019

@vanfanel

This comment has been minimized.

Copy link

@vanfanel vanfanel commented May 2, 2019

@antonellocaroli : Great! What other options, appart from GENERAL SETUP->PREEMPTION MODEL can you recommend me to change?
In KERNEL FEATURES->TIMER FREQUENCY, I already have 1000Hz (default in 4.14.y and 4.19.y branches anyway).

@antonellocaroli

This comment has been minimized.

Copy link
Author

@antonellocaroli antonellocaroli commented May 2, 2019

@vanfanel
you just need them...
but take a look at this to find out more:
https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions

@vanfanel

This comment has been minimized.

Copy link

@vanfanel vanfanel commented May 3, 2019

@antonellocaroli : Thanks! I read that document time ago.
What I usually do to set realtime priority on a process is:

  1. Set the rlimits system-wide accordingly so normal users can set realtime priority.
  2. Execute the process with chrt -f 80 <executable name>
    If you have any other observation regarding RT on GNU/Linux, please share it.
@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented May 12, 2019

Following, so I can get RealtimePi to point to it when ready

@NikiSchlifke

This comment has been minimized.

Copy link

@NikiSchlifke NikiSchlifke commented May 20, 2019

+1

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented May 21, 2019

Just realised no one actually mentioned @TiejunChina . So no wonder this has been hanging for 25 days.

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented May 21, 2019

Tiejun is well aware of the situation. Pinging him (which I intentionally avoided) won't help.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented May 21, 2019

@pelwell Understood, it did not happen here and I could not guess at your private communication. Apologies.

I recommend notifying that next time, since I was starting to speculate on making my own PR branch.

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented May 21, 2019

I was starting to speculate on making my own PR branch.

I wouldn't have a problem with that, if you can follow the same format as Tiejun did. The standard rpi- branches use merge commits to pull in upstream patches so they keep their commit IDs, and cherry-ick/rebase downstream commits to keep the commit history clear - you end up with two parallel streams of commits, "us" and "them".

As I wrote to Tiejun at the time:

"One of our internal rules is that, apart from back-porting patches to older kernels, we never change the upstream commits. This means that our development looks like this:

    L-L-L-L-L-L-L---L-L-L-L-L-L-L     = Upstream Linux
                 \       \       \
                  P-P-P-P-M-P-P---M-P = Downstream rpi- branch
                      ^   ^       ^
                      A   B       C

where L is an upstream Linux commit, P is a downstream Pi commit, and M is a merge commit. A represents the point where we stop rebasing our commits against the new kernel version, which corresponds to the point where it becomes our mainline branch. B and C are minor kernel version updates.

"Perhaps you could structure the -rt branch like this:

    L-L-L-L-L-L-L----L-L-L-L-L-L-L     = Upstream Linux
                \         \       \
                 R-R-R-R-M-M--M----M-M = rpi-rt branch
                        /    /     /
                 P-P-P-P--P-P-----P    = Downstream rpi- branch

"I hope you can understand my diagram. The important point is that the L and P commits in this diagram are identical to those in the previous one, with the same commit hash. The nice thing about this scheme is that by not rebasing your existing commits you only need to work on and think about (and fix) new commits."

If you can follow that pattern and prepare a branch in your repo then I'll be happy to bless it and call it rpi-4.19-rt. If, in doing so, you end up creating any tools to simplify the task then let me know - should it become easy enough then eventually the task may be brought in-house.

@paul-1

This comment has been minimized.

Copy link

@paul-1 paul-1 commented May 21, 2019

Merging Upstream Linux commits into the RT branch is fun. I've never kept a copy of the rt-kernel git.

When maintaining for myself, when there is a new -rtxx version, I start from a clean rpi branch, and apply the rt patch set, then cherry pick any rpi-rt commits. I know that some don't like constant rebasing, but in my mind keeps the rt branch only a few commits different than the normal rpi branch.

@TheLongAndOnly

This comment has been minimized.

Copy link

@TheLongAndOnly TheLongAndOnly commented May 26, 2019

@paul-1 As I understood you managed to get the RT patches to work for 4.19. I tried myself but ran into problems and hope you might have some hints.

As patching 4.19.y HEAD did not work, I pulled the matching commit for 4.19.37. These are the steps I took:

  • git clone https://github.com/raspberrypi/linux.git --single-branch --branch rpi-4.19.y
  • git checkout 19bb613
    (this is the commit changing to version 4.19.37)
  • make bcm2709_defconfig (had to pull it from head, as it is not part of the commit)
    As the debos are not build, I updated to the correct commit of rpi-update
  • sudo rpi-update 6cf2788e74b497c109865d052cd6fa68d094cf38

Unfortunately after installation of the new kernel I do not get past the rainbow screen. Changing kernel7.img back to the original one makes the system boot.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented May 26, 2019

@paul-1

This comment has been minimized.

Copy link

@paul-1 paul-1 commented May 27, 2019

RPI is rebasing the 4.19.y tree, you cannot go back like that right now, unless you go and then pick all of the rpi downstream commits. did you try to apply the 4.19.37-rt19 against the current branch? Otherwise it's best to wait until the next rt patch comes out.

@TheLongAndOnly

This comment has been minimized.

Copy link

@TheLongAndOnly TheLongAndOnly commented May 27, 2019

Ok, I didn't realize this, but it explains why the configs are missing. Applying 4.19.37-rt19 to the current branch does not work as there have been changes to mainline which makes the build fail.

@paul-1

This comment has been minimized.

Copy link

@paul-1 paul-1 commented Jun 18, 2019

4.19.50-rt22 is out, it applies cleanly against the current rpi branch.

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented Jun 18, 2019

Thanks for the tip.

@paul-1

This comment has been minimized.

Copy link

@paul-1 paul-1 commented Jun 18, 2019

I have not been applying that for a while, and definitely not on the 4.19 branch, I have not noticed a problem. But I've not done a ton of heavy USB testing.

Edit: You may be correct, I think with all the 4.19 changes, I made a mistake in my defconfig.

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented Jun 18, 2019

Please take a look at https://github.com/pelwell/linux/tree/rpi-4.19.y.rt . It's a simple merge of the current rpi-4.19.y.rt with the RT commits on top. I've also copied across one of Tiejun's commits. Other than building it and booting it on a 3B+ I've not done any real testing, but if people think it's OK then I'm happy to push it as a semi-official, low-priority-supported branch off raspberrypi/linux.

@paul-1

This comment has been minimized.

Copy link

@paul-1 paul-1 commented Jun 18, 2019

Should you change the defconfigs in that branch for
CONFIG_PREEMPT_RT_FULL=y

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented Jun 18, 2019

Good point. I've updated the branch with updated defconfigs, but without the cherry-pick of Tiejun's patch (it was locking up for me with that included).

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented Jun 18, 2019

I'm also using dtoverlay=dwc2.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Jun 18, 2019

@paul-1

This comment has been minimized.

Copy link

@paul-1 paul-1 commented Jun 18, 2019

I'm using the standard dwc_otg driver (With fiq & fsm enabled).......I've never had good luck with the dwc2.

I've confirmed that the patch "don't thread shared irqs" from Tiejun is needed if SPI is enabled. I also applied the patch from osadl.org, but there has been changes to the dwc_otg driver that still hangs the system. I believe this commit adds a spot that needs to be locked with the fiq_fsm_spin_lock_irqsave 3ea9af8 after patching that part, kernel has been stable.....but doing more testing now.

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented Jun 18, 2019

Thanks for the feedback. You could probably save some time and effort if you could submit a Pull Request with the necessary changes, otherwise I'll have another go when I can.

@paul-1

This comment has been minimized.

Copy link

@paul-1 paul-1 commented Jun 18, 2019

I will once I do some validation.....I don't want to make mistakes that I made with earlier RT builds.

@paul-1

This comment has been minimized.

Copy link

@paul-1 paul-1 commented Jun 30, 2019

It's a bit out of my understanding to play with interrupts. What I have works for our application (piCorePlayer) as most of our users are not interested in using the serial line in a RT environment. That appears to be the big problem maker.

Now if I could just get my hands on my pi4 shipments, I could get to work.

@TiejunChina

This comment has been minimized.

Copy link
Collaborator

@TiejunChina TiejunChina commented Jul 1, 2019

Ok, I have a nightly that boots, using the branch. uname:

Linux realtimepi 4.19.50-rt22-v7 #2 SMP PREEMPT RT Sat Jun 29 10:17:23 BST 2019 armv7l GNU/Linux

What didnt' work:

  • keyboard
  • ethernet

what worked:

  • boots
  • wifi and ssh
  • 3B+
  • 3A+

Download at:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-06-29_2019-06-20-realtimepi-buster-lite-0.4.0.zip
md5:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-06-29_2019-06-20-realtimepi-buster-lite-0.4.0.zip.md5

Binary:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-06-29_realtimepi-kernel-4.19.50.tar.gz

Also upgraded to buster.

I think we need to add the usb-dwc_otg-fix for the keyboard to waork.

@guysoft I'm got stuck in my regular work so sorry for this inconvenience. Did you try our rpi-4.14.-rt? Even we decided not to upgrade that but I recall 'keyboard' and 'ethernet' both worked on my 3b board.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Jul 1, 2019

@TiejunChina Hey, good to see you back.
Yes I have an RC for that:
guysoft/RealtimePi#16

We will need though eveltually to move to rpi-4.19-rt.

@TiejunChina

This comment has been minimized.

Copy link
Collaborator

@TiejunChina TiejunChina commented Jul 3, 2019

@guysoft my rpi-4.14-rt can work very well on my target.

pi@raspberrypi:/boot$ cat cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=7e31a93c-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
pi@raspberrypi:/boot$ cat config.txt
.# For more options and information see
.# http://rpf.io/configtxt
.# Some settings may impact device functionality. See link above for details

.# uncomment if you get no picture on HDMI for a default "safe" mode
.#hdmi_safe=1

.# uncomment this if your display has a black border of unused pixels visible
.# and your display can output without overscan
.#disable_overscan=1

.# uncomment the following to adjust overscan. Use positive numbers if console
.# goes off screen, and negative if there is too much border
.#overscan_left=16
.#overscan_right=16
.#overscan_top=16
.#overscan_bottom=16

.# uncomment to force a console size. By default it will be display's size minus
.# overscan.
.#framebuffer_width=1280
.#framebuffer_height=720

.# uncomment if hdmi display is not detected and composite is being output
.#hdmi_force_hotplug=1

.# uncomment to force a specific HDMI mode (this will force VGA)
.#hdmi_group=1
.#hdmi_mode=1

.# uncomment to force a HDMI mode rather than DVI. This can make audio work in
.# DMT (computer monitor) modes
.#hdmi_drive=2

.# uncomment to increase signal to HDMI, if you have interference, blanking, or
.# no display
.#config_hdmi_boost=4

.# uncomment for composite PAL
.#sdtv_mode=2

.#uncomment to overclock the arm. 700 MHz is the default.
.#arm_freq=800

.# Uncomment some or all of these to enable the optional hardware interfaces
.#dtparam=i2c_arm=on
.#dtparam=i2s=on
.#dtparam=spi=on

.# Uncomment this to enable the lirc-rpi module
.#dtoverlay=lirc-rpi

.# Additional overlays and parameters are documented /boot/overlays/README

.# Enable audio (loads snd_bcm2835)
dtparam=audio=on
pi@raspberrypi:/boot$ uname -a
Linux raspberrypi 4.14.91-rt49-v7+ #32 SMP PREEMPT RT Mon Jan 7 11:29:31 CST 2019 armv7l GNU/Linux

@TiejunChina

This comment has been minimized.

Copy link
Collaborator

@TiejunChina TiejunChina commented Jul 3, 2019

Let's first check if rpi-4.14.y-rt can work on your target.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Jul 3, 2019

@TiejunChen It does, there is a release candidate out with rpi-4.14.y-rt .
guysoft/RealtimePi#16

It boots and works.
Also got confirmation from several users.

The issue is with rpi-4.19-rt.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Jul 10, 2019

Getting more reports - it seems like it works, but only if you set dwc_otg.lpm_enable=1, which I am guessing means we need usb-dwc_otg-fix to be patched.
See: guysoft/RealtimePi#13 (comment)

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Jul 14, 2019

Also, getting reports that this branch is not working for RaspberryPi 4 :guysoft/RealtimePi#17

Have the build instructions changed?

@TiejunChina

This comment has been minimized.

Copy link
Collaborator

@TiejunChina TiejunChina commented Jul 14, 2019

@guysoft I just ordered one pi4 last month but in China we will have to receive that next month. I'll check this once I get that.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Jul 15, 2019

@TiejunChina Know well that feeling when you have bugs open in your codebase and no access to the hardware.
Ping us once you get it. Also feel free to ask people in my project to test stuff if that helps (issue guysoft/RealtimePi#17 ).

Also there are interesting reports here of people testing stuff:
https://forum.linuxcnc.org/18-computer/36879-raspberry-pi-4?start=0#138874

@TiejunChina

This comment has been minimized.

Copy link
Collaborator

@TiejunChina TiejunChina commented Jul 23, 2019

@guysoft @pelwell @paul-1 I just refreshed rpi-4.19.y-rt as
4.19.59 + v4.19.59-rt23 + rpi-4.19.y patches against 4.19.59 + "usb: dwc_otg: fix system lockup when interrupts are threaded" + "Don't need to use _nort" + "Enable CONFIG_PREEMPT_RT_FULL". I also enabled RT for bcm2711_defconfig as well.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Aug 5, 2019

In the process of building a new image.
Will update when I have an image.
Should I also update the cmdline.txt to something else?

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Aug 6, 2019

Ok getting a strange behaviour.

It builds then stops in the middle:

+ make ARCH=arm bcmrpi_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
  LEX     scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
arch/arm/configs/bcmrpi_defconfig:32:warning: override: PREEMPT_RT_FULL changes choice state
#
# configuration written to .config
#
+ echo 'CONFIG_PREEMPT_RT_FULL=y
CONFIG_DEBUG_PREEMPT=n
CONFIG_PREEMPT_TRACER=n
CONFIG_RCU_CPU_STALL_TIMEOUT=21'
+ make -j4 zImage modules dtbs
scripts/kconfig/conf  --syncconfig Kconfig
.config:6391:warning: override: reassigning to symbol PREEMPT_RT_FULL
.config:6391:warning: override: PREEMPT_RT_FULL changes choice state
.config:6392:warning: override: reassigning to symbol DEBUG_PREEMPT
.config:6393:warning: override: reassigning to symbol PREEMPT_TRACER
.config:6394:warning: override: reassigning to symbol RCU_CPU_STALL_TIMEOUT
  SYSHDR  arch/arm/include/gen

[....]

  AR      drivers/char/ipmi/built-in.a
  AR      drivers/clk/actions/built-in.a
  CC [M]  net/ax25/ax25_uid.o
  CC      drivers/clk/bcm/clk-bcm2835.o
+ chmod 777 /mnt/sdc1/RealtimePi/src/build_dist /mnt/sdc1/RealtimePi/src/build.log /mnt/sdc1/RealtimePi/src/config /mnt/sdc1/RealtimePi/src/custompios_path /mnt/sdc1/RealtimePi/src/docker-compose.yml /mnt/sdc1/RealtimePi/src/image /mnt/sdc1/RealtimePi/src/image-variants /mnt/sdc1/RealtimePi/src/modules /mnt/sdc1/RealtimePi/src/vagrant /mnt/sdc1/RealtimePi/src/variants /mnt/sdc1/RealtimePi/src/workspace

Thats the last line, it just doesn't continue without any message.
That didn't happen before the update.

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented Aug 6, 2019

What is mounted on /mnt/sdc1? Have you run an fsck on it recently?

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Aug 6, 2019

/dev/sdc1 is a harddrive where the image is being built.
I unmounted it and ran fsck (has been mounted 84 times without being checked, check forced. so i guess its a good thing to do anyway).

Mounting again and building, will see if there is a change, but doubt it because it failed at the same place twice.
Will update.

@pelwell

This comment has been minimized.

Copy link
Contributor

@pelwell pelwell commented Aug 6, 2019

Since it always fails in the same place, you could try running that chmod command on its own. It's also possible that it's the next command, the one it hasn't shown, that takes forever...

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Aug 8, 2019

@pelwell, ok, unmounting the docker environment and remounting fixed it. Strange but fixed :)

Image:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-07_2019-07-10-realtimepi-buster-lite-0.4.0.zip
md5:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-07_2019-07-10-realtimepi-buster-lite-0.4.0.zip.md5

kernel only that you can untar on top of an existing raspbian:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-07_realtimepi-kernel-4.19.59.tar.gz

Note: I didn't change the cmdline.txt mentioned here:
#2943 (comment)
Likely now that the usd owc patch is in place I can remove that, rebuild, and hopefully release.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Aug 26, 2019

Users are reporting at RealtimePi that usb-dwc_otg-fix does not help, is it merged in the tree?
If so, could there have been changes to the USB driver now that it also uses USB 3?

@TiejunChina

This comment has been minimized.

Copy link
Collaborator

@TiejunChina TiejunChina commented Aug 27, 2019

Are you talking about this ?
801df5a

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Aug 27, 2019

@TiejunChina Yes, it seems like the USB when enabled freezes the system on boot. There was a major change in the kernel in that aspect, so I would guess its there, but we really should find a way to debug what is going on there.

@sebastiannielsen

This comment has been minimized.

Copy link

@sebastiannielsen sebastiannielsen commented Aug 28, 2019

And debugging becomes a little bit complicated since the whole system freezes. Is there some diff of the change, maybe the changes in the kernel could be analyzed and the "corresponding" changes in the fix code could be applied (kind of "blind fix")?

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Aug 29, 2019

It might be I already had. This is the output I got earlier on:
#2943 (comment)
used kgdboc=ttyS0,115200 which gives more output on boot for the kernel.

Might be worth trying to add that on boot and see if we are still getting that error or if its something new.

@rlillback

This comment has been minimized.

Copy link

@rlillback rlillback commented Oct 19, 2019

Is there any update on the progress? I have been attempting to patch this as well. I either get the Kernel panic's described above or the system boots without Ethernet and USB active.

@guysoft

This comment has been minimized.

Copy link

@guysoft guysoft commented Oct 24, 2019

The current status is that this only works if you set dwc_otg.lpm_enable=1.
This means the current patch for the USB driver does not work with the new kernel and needs to be re-written. This means someone with knowledge of what is going on in the kernel needs to step in and write code. Which is none of us who are just using exiting patches.

The original patch was AFAIK was published here. By @oghorbel . But I have yet to reach him to provide input.

schnitzeltony added a commit to schnitzeltony/linux-raspberrypi that referenced this issue Nov 16, 2019
What I did - no rocket science [1]:

* Applied RT-patches 4.19.72-rt26 on top of rpi-4.19.y / 4.19.79 (most recent
  version applying rt-patch properly)
* Applied a slightly rebased version of the original (4.14) fiq-patch [2]
* grepped for 'fiq_fsm_spin_lock(' and 'fiq_fsm_spin_unlock(' and added missing
  rt-specific replacements
* rebased changes back to rpi-4.19.y-rt

What this patch does:

* add one missing pair of fiq_fsm_spin_lock/fiq_fsm_spin_unlock replacements

With builds of [1] Rapsi3 is running without a singe issue for two weeks now
and it was stressed by

* moving gigabytes from USB-Stick to SDCard
* several usb-midi-keyboard jam sessions

Addresses [3]

[1] https://github.com/schnitzeltony/meta-raspi-light/tree/master/recipes-kernel/linux
[2] raspberrypi@05dd5c4
[3] raspberrypi#2943

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
schnitzeltony added a commit to schnitzeltony/linux-raspberrypi that referenced this issue Nov 17, 2019
What I did - no rocket science [1]:

* Applied RT-patches 4.19.72-rt26 on top of rpi-4.19.y / 4.19.79 (most recent
  version applying rt-patch properly)
* Applied a slightly rebased version of the original (4.14) fiq-patch [2]
* grepped for 'fiq_fsm_spin_lock(' and 'fiq_fsm_spin_unlock(' and added missing
  rt-specific replacements
* rebased changes back to rpi-4.19.y-rt

What this patch does:

* add one missing pair of fiq_fsm_spin_lock/fiq_fsm_spin_unlock replacements

With builds of [1] Rapsi3 is running without a singe issue for two weeks now
and it was stressed by

* moving gigabytes from USB-Stick to SDCard
* several usb-midi-keyboard jam sessions

Addresses [3]

[1] https://github.com/schnitzeltony/meta-raspi-light/tree/master/recipes-kernel/linux
[2] raspberrypi@05dd5c4
[3] raspberrypi#2943

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.