tty-Treiber 2.17 HmIP/multimacd für Raspbian Jessie? #33
Comments
|
Ich würde nicht so schnell den Thread schließen, das beigefügte Treiber für eq3loop lässt sich mit kleinen Korrekturen auf einem neueren Kernel ab 3.10 bauen, mxs_raw Treiber ist aber für den Betrieb mit aktuellen Treibern nicht geeignet :(, das Ganze Proc geraffel muss umgeschrieben werden |
|
Der mxs_raw Treiber ist ein CCU2 spezifischer Treiber. Der mxs_raw Treiber greift direkt auf die UART Hardware des ARM SOC zu. Eine Version für den Raspberry PI 2 habe ich soeben im RaspberryMatic Repro zur Verfügung gestellt (https://github.com/eq-3/RaspberryMatic/blob/master/linux-4.1/drivers/char/broadcom/bcm2835_raw_uart.c) |
|
Danke für die schnelle Bereitstellung, habe den Code durch den Compiler auf aktuellen Raspbian gejagt und es läuft ohne Probleme durch, allerdings habe ich keinen Device unter /dev oder müsste ich den selbst anlegen? entsprechend kommt multimac nur bedingt hoch. auch wenn ich das device selbst anlege nicht |
|
Auch auf einem 4.1er Kernel kommt das Device nicht hoch, oder verstehe/mache ich etwas falsch? Linux raspberrypi 4.1.20-v7+ #867 SMP Wed Mar 23 20:12:32 GMT 2016 armv7l GNU/Linux |
|
Habt ihr den original Treiber für den UART im Kernel abgeschaltet (bzw. das Modul nicht geladen)? |
|
Ich habe das Quelltest um einige Debug Nachrichten erweitert, leider ohne Erfolg. so wird die Methode "init" ausgeführt, dadrin die Funktion platform_driver_register aufgerufen, welche 0 als Rückgabewert ausspuckt, danach kommt leider nichts. Auf dem System sind neben HM-MOD-RPI-PCB keine weiteren Module angesteckt. Anbei lsmod Output wenn Module geladen wurde sowie /dev/ und dmesg |
|
Auf die Schnelle fällt mir auf, dass in der Liste der Devices /dev/ttyAMA0 auftaucht. Der original Treiber scheint also aktiv zu sein. Die Konfiguration die wir für die RaspberryMatic verwenden findet sich unter https://github.com/eq-3/RaspberryMatic/blob/master/linux-4.1/arch/arm/configs/raspberrymatic_defconfig |
|
Danke für die Infos Sollte es daran liegen, so schränkt es die Nutzung des Moduls extrem ein, man müsste, sofern man homematic IP nutzen möchte, einen neuen Kernel ohne amba_pl011 bauen. Die ttyAMA0 kommt von dem Treiber und lässt sich nicht deaktivieren. Auch wenn die Serielle Konsole bereits auf tty1 umgeleitet wurde, ist der Treiber im Kernel und wird beim Start geladen Schade, ggf. findet ihr einen Weg die Module etwas "Benutzerfreundlicher" ;) zu machen Gruß Leo Verweise: |
|
Ich habe mir die Mühe gegeben aktuelles Kernel neu zu kompilieren ohne amba_pl011 Modul. Beim laden das gleiche Spiel platform_driver_register gibt 0 zurück, weitere Methoden/Funktionen werden nicht aufgerufen. Also sollte es nicht an dem Kernel liegen |
|
Hallo git es etwas neues von der Baustelle? Ich kann das Modul zwar bauen, aber ein Interface erscheint nicht :( Gruß Leo |
|
So trots das ich eine stunde eben im Stau gestanden habe, bin ich irgendwie gut drauf daher sage ich mal wo deine Probleme liegen. Ich gehe jetzt mal davon aus das du die beiden Dateien aus dem raspberry Kernel also raspberrymatic integriert steht ja oben.
Und so geht es in der heutigen Folge von ............. weiter :).
IN:linux-4.1/arch/arm/mach-bcm2709/bcm2709.c EINFÜGEN: und dann Zeile steht ja da: @@ -931,6 +954,10 @@ void __init bcm2709_init(void) Einfügen: @@ -1158,6 +1185,7 @@ static inline void bcm2709_init_led(void
und in: Coprocessor Device Path = /dev/bcm2835-raw-uart nicht bcm2835-raw-uart.0 danach werden alle driver erstellt und auch erkannt ( allerdings gehen die Probleme dann immer noch weiter oder vielleicht auch erst los wer weiss ;) ). *Dies kann für nicht hardware heute einfach übersprungen werden *1. WARUM ZUM TEUFEL TTYS0 * *2. Warum 2 firmware im Upload * Nur zur info getestet habe ich das von Kernel 4.1 - Kernel 4.4 auf Raspberry. Ach du Schande dieser Editor zum schreien ist der horror. Ist grösser geworden als ich vor hatte, egal ich hoffe es hilft dir. Gruß |
|
Hi Danke ich versuche es morgen durchzuspielen, wenn ich wieder nüchtern bin. Loop device habe ich bereits zum laufen bekommen und bin bis jetzt am uart device gescheitert |
|
grr finde es zum Kotzen, dass nicht alles als Modul geliefert wird und an den original Kernel-Source Veränderung durchführt :( Nachtrag falls Interesse besteht suche: Lösche alles bis zum Ende bzw, ersetze es durch Damit wird zumindest das RAW Device angelegt, ob es auch tatsächlich funktioniert kann ich mangels HM-IP Geräte nicht testen (wollte es Vollständigkeit weise gebaut haben) |
|
Schon wer erfolgreich das Modul auf 4.4er Kernel zum Laufen bekommen? |
|
Im Zuge der Arbeiten an RaspberryMatic (http://github.com/jens-maus/RaspberryMatic) habe ich mir nun auch die besagten kernel module angeschaut und auch für Kernel 4.4 mit den hier genannten Änderungen kompiliert bekommen. Während das Gibt es denn schon neuere Erkenntnisse was hier genau geändert werden müsste damit das Modul mit einem aktuellen Kernel 4.4 korrekt funktioniert und das /dev device dafür dann korrekt initialisiert wird? Wenn nicht müsste ich mir das hier mal schrittweise nochmal anschauen – wollte aber erst einmal hier nachfragen ob es neuere Infos gibt?!? Die Arbeiten bzgl. RaspberryMatic und den kernel modules kann hier (https://github.com/jens-maus/RaspberryMatic/tree/master/buildroot-external/package/homematic/kernel-modules) eingesehen werden. |
|
Nach etwas eigener Analyse der Situation und des Fehlers warum das bcm2835_raw_uart kernel modul nicht laden wollte hab ich nun einen Weg gefunden das Modul zum korrekten laden bei Kernel Versionen >= 4.3 gefunden. Siehe hier: jens-maus/RaspberryMatic@c188573 Das problem war hierbei das in Kernel 4.3 anscheinend der "dev:f1" clock provider für die UART clock entfernt wurde und das Modul nun selbst eine fixed clock generieren muss. Der hier genannte Patch sollte das Problem beheben. Ob das allerdings nun final zum erfolg geführt hat das HmIP Komponenten damit auch laufen kann ich selbst leider noch nicht sagen. |
|
ich baue dies ins YAHM ein und lasse die Community testen, habe selbst keine IP Geräte im Einsatz |
|
Wunderbar, mach das. Die aktuellen Quellen der kernel-module für Kernel 4.4 angepasst findest du übrigens hier: Eine Warnung diesbzgl. hab ich aber bereits (vor allem da du diese ja in deiner container-Lösung einsetzen willst): das bcm2835-raw-uart Modul macht es notwendig einen Host kernel (d.h. bei dir von Raspbian) einzusetzen bei dem der PL011 UART driver komplett deaktiviert ist bzw. als Modul kompiliert ist und nicht in den kernel reinkompiliert ist. D.h. beim hochfahren darf es weder /dev/ttyAMA0 noch /dev/ttyS0 geben. Im grunde heisst das dann das du mitunter einen eigenen Kernel mit YAHM ausliefern musst wenn HmIP funktionieren soll - und dieser muss auch Bluetooth entsprechend abschalten. Aktuell hab ich auch gerade für den RPi3 noch gewisse Probleme mit dem Modul die ich mir gerade anschaue. |
|
Ich habe versucht das alles auf einem frischen Pi2 (um die Pi3 Probleme erstmal zu umgehen) mit Jessie Lite nachzuvollziehen. Kernel kompiliert ohne PL011, die zwei Module kompiliert und installiert. Bis hier alles problemlos: die standard devices Ich bekomme allerdings multimacd und rfd nicht richtig zum laufen. Beide werden zwar ausgeführt, aber die rfd.log liefert Mein Verständnis aus dem PDF von eq3 war dass der multimacd das slave device In def Beim Versuch das FW-update manuell anzustossen mit RFD hat vorher mit dem Modul im "Homematic-Only" Betrieb einwandfrei funktioniert, deshalb glaube ich nicht dass keinerlei FW auf dem Modul installiert ist. Ich stehe auf dem Schlauch - bin für jeglichen Tipp dankbar!!! Wahrscheinlich sehe ich den Baum vor lauter Bäumen nicht. |
|
Bevor man sich an das starten von RFD/multimac macht sollte man in der Tat erst einmal die Abfrage der aktuellen Firmware version mittels Wenn das schon nicht klappt, dann funktioniert das bcm2835-raw-uart kernel Modul nicht korrekt. Welche Quellen dieses Modules hast du denn verwendet? Und welche Kernel version nutzt du denn exakt? Kann gut sein das das im Grunde ein ähnliches Problem ist wie das noch aktuelle Problem mit dem RaspberryPi3 und RaspberryMatic. Zusätzlich kann man nach laden des modules und dem ersten nutzen des devices auch noch in /proc/interrupts und /proc/iomem schauen ob die Ressourcen für das kernel Modul richtig zugewiesen sind. Das ganze muss ähnlich wie diesem aussehen: Auf einem RPi3 unter RaspberryMatic wird die ausgabe des IRQ z.B. nicht gezeigt wieso ich immer noch denke das da irgendetwas prinzipielles beim Ressourcen allokieren im kernel Modul schief geht bzw. nicht ganz auf die Bedingungen in neueren Linux kernel Versionen abgestimmt ist. |
|
Ich habe die für Kernel 4.4 angepassten Quellen aus deinem Link oben genommen. Kernel Version ist 4.4.39-v7+. Die Resourcenzuordnung war anscheinend ein Volltreffer - in /proc/interrupts kein Zeichen von bcm2835-raw-uart (/proc/iomem scheint ok). Neustart ohne "Ballast": Ich werde wohl mal mit ner frischen SD-Karte von vorne anfangen... Sollte ich eine bestimmte minor version von kernel 4.4 verwenden? |
|
Das kann ich dir nicht sagen. Leider hab ich das Problem (das ich eben auch mit nem RPi3 unter RaspberryMatic habe) noch nicht ganz verstanden und mir fehlt dafür noch das tiefere Verständnis des Kernel modules und wie das genau initialisiert gehört damit auch alle Ressourcen korrekt und automatisch allokiert werden. Momentan setze ich ja z.b. einen festen IRQ von 87 in den kernel module quellen was aber mitunter nicht immer so gegeben sein sollte. Auch musst du beachten das der IRQ nur zugewiesen wird sobald du das erste mal probierst das bcm2835-raw-uart device zu nutzen (z.B: mittels eq3configcmd). Auch deine /proc/iomem ausgabe zeigt z.B. keine "/soc/uart@7e201000" zeile. |
|
Ich hatte zuerst pures HM aufgesetzt mit einem alten commit von occu noch ohne HMip und alles lief (konnte mit RFD über port 2001 kommunizieren, Geräte anlernen etc.). Hier nochmal vom letzten Versuch:
|
|
Ich denke das neuaufsetzend kannst du dir sparen. Als erste Voraussetzung für einen funktionierenden HmIP Support ist, das das /dev/bcm2835-raw-uart device korrekt funktioniert und die simplen eq3configcmd befehle z.B. zum auslesen der Seriennummer und Firmware version des Funkmoduls korrekt funktionieren. Wenn das nicht der Fall ist brauch man mit rfd/multimacd gar nicht beginnen. Und das Die Arbeit wäre also IMHO besser darin investiert das kernel Modul ans laufen zu bekommen, das benötigt allerdings Erfahrung mit linux kernel Modul Entwicklung, die ich selbst auch nur limitiert habe. |
|
Meine Linux Kernel Modul-Entwicklungs Kenntnisse sind auch eher limitiert... ich versuche mich gerade einzulesen und habe zwei interessante Hinweise gefunden (wahrscheinlich sind das nur für mich Neuigkeiten und für euch kalter Kaffee, aber vielleicht hilft es ja):
|
|
In der Tat sind das nicht ganz neue Informationen für mich. Das man ein Auch das man |
|
Hat der Treiber in der Version von hier Edit: Sorry, meinte natürlich die Triber von |
|
Nun, das das bcm2835-raw-uart Modul prinzipiell ja funktioniert zeigt ja der RaspberryPi2+HmIP Support in der neuesten RaspberryMatic beta3 version. Ich hab in den Quellen ja auch schon bereits die unterschiede zwischen kernel 4.1 und 4.4. eingearbeitet. Dort wurde im Grunde an ARMctrl gearbeitet und dieses komplett gegen device trees ersetzt. Verstehe ich noch nicht zu 100%, aber die änderungen die ich eingearbeitet habe haben prinzipiell ja dazu geführt das das Modul auf einem Pi2 mit kernel 4.4 funktioniert (zumindest unter dem buildroot system das RaspberryMatic verwendet). Warum du das allerdings nicht unter einem normalen Jessie mit kernel 4.4 hinbekommst kann ich dir auch nicht sagen – das hab ich noch nicht ausprobiert. Es wird aber übrigens auch von Seiten von eQ3 prinzipiell daran gearbeitet das kernel Modul für einen RPi3 hinzubekommen sodass ich zuversichtlich bin hoffentlich in nächster zeit ein kernel Modul zu haben das unter kernel 4.4+Rpi3 auch funktioniert. Ich vermute wie gesagt einfach gewisse Probleme in der Initialisierung (Zuweisung IRQ+IOMEM) des kernel Moduls die sich mit genügend KnowHow wohl recht einfach beseitigen lassen sollten. |
|
Ich sehe schon, ich werde mich erstmal vermehrt mit RaspberryMatic beschäftigen, sonst stelle ich zu viele schon beantwortete Fragen :) |
|
Ja, da hat sich einiges geändert. Hilfe von Leuten die etwas mehr Erfahrung bei der Linux-Kernel Entwicklung haben wäre hier wirklich angebracht. die eQ3-Entwickler wollten/wollen hier auch noch in nächster Zeit unter die Arme greifen sodass ich hoffe das wir diese Probleme ggf. bereits noch im Januar in den Griff bekommen und für alle Plattformen ein lauffähiges bcm2835-raw-uart haben. |
|
Ich habe mein Pi2 Problem "gelöst" - oder besser umgangen... |
|
Laut buildroot nutzt die 2016.05 Version die in RaspberryMatic verwendet wird die firmware Version vom 6.Mai Bzgl. Pi3: die Änderungen für "enable_uart" in der config.txt wurden erst danach (am 12.Mai) in den bootloader eingebaut, der bootloader in RaspberryMatic wird also wahrscheinlich noch anders oder überhaupt nicht auf diese Einstellung reagieren... Edit: der Commit vom 23. August ist für das Problem verantwortlich. Das macht nach der Beschreibung auch Sinn: |
|
Das war tatsächlich das Problem. Eine einfache Änderung der UART0_CLOCK von 3000000 auf 48000000 im Quellcode vom bcm2835_raw_uart führt zum Erfolg mit der aktuellen start.elf bein Pi2: Idealerweise sollte man die aktuelle clock-rate auslesen können (aus dem device tree?) statt sie hardcoden zu müssen. Es gibt ein paar Kommentare dass die clock-rate beim Pi3 schon vor dieser Änderung auf 48000000 hochgesetzt wurde. Falls das so ist, könnte diese Änderung vielleicht auch das Pi3 Problem lösen??? Edit: ich konnte das gerade auf einem Pi3 verifizieren. Das Modul funktioniert nach der Änderung der Frequenz auch mit einem Pi3 und der aktuellen start.elf. |
|
Das sind ja wirklich gute Neuigkeiten und hört sich sehr vielversprechend an das das in der Tat die Lösung des problems ist. Danke für die Analysen, ich werde versuchen das ganze selbst zu testen sobald ich wieder zuhause bin und das mit einem Pi3 live testen kann. Deine Analysen machen aber mehr als sinn und das passt auch zu meiner Vermutung das es im Grunde nur eine Kleinigkeit ist/war die das Modul davon abgehalten hat das es auf einem Pi3 läuft. |
|
Hier nur der kurze Hinweis das ich nun Zeit hatte deine Hinweise bzgl. RaspberryPi3 und bcm2835-raw-uart Modul bzw. 48MHz vs 3MHz für die uart clock Frequenz zu testen. In der Tat hat das nun dazu geführt das das bcm2835-raw-uart Modul nun auch auf einem RaspberryPi3 funktioniert nachdem ich die clock Frequenz im kernel Modul auf 48MHz gestellt habe. Danke dafür! Damit eine RaspberyPi2 Unterscheidung nicht notwendig ist habe ich nun auch kurzerhand in die |
|
Prima. |
|
Wunderbar, danke für die Info. Da ich gerade auch ein upgrade auf buildroot 2016.11 mache bin ich gespannt welche Auswirkungen es diesbzgl. dann auch geben wird. Für RaspberryMatic ist das neukompilieren eines Kernels ohnehin aber nicht so kritisch da im build-prozess ohnehin der kernel mit eigener config neu kompiliert wird. |
|
ich hab bei mir yahm mit HmIP auf jessie-light zum Laufen gebracht. Ich denke mal die wichtigsten Punkte ware das durchreichen der Devices in den Kontainer und das Upgrade des Moduls. Gruß |
|
Danke ich werde es testen
… Am 22.01.2017 um 16:19 schrieb hcanchristian ***@***.***>:
ich hab bei mir yahm mit HmIP auf jessie-light zum Laufen gebracht. Ich denke mal die wichtigsten Punkte ware das durchreichen der Devices in den Kontainer und das Upgrade des Moduls.
Meine Vorgehensweise:
Module laden:
/opt/YAHM/share/tools/rpi-source/rpi-source
mkdir mymods
cd mymods
wget https://github.com/jens-maus/RaspberryMatic/raw/master/buildroot-external/package/homematic/kernel-modules/bcm2835_raw_uart/bcm2835_raw_uart.c
wget https://github.com/jens-maus/RaspberryMatic/raw/master/buildroot-external/package/homematic/kernel-modules/eq3_char_loop/eq3_char_loop.c
Makefile anlegen (Format stimmt nicht ganz wegen des Editors):
MODSRC=/root/mymods
obj-m += bcm2835_raw_uart.o
obj-m += eq3_char_loop.o
all:
make -C /lib/modules/$(shell uname -r)/build M=${MODSRC} modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=${MODSRC} clean
Module bauen und installieren:
make
cp eq3_char_loop.ko /lib/modules/$(uname -r)/kernel/drivers/char/
cp bcm2835_raw_uart.ko /lib/modules/$(uname -r)/kernel/drivers/char/broadcom
depmod -a
insmod eq3_char_loop.ko
insmod bcm2835_raw_uart.ko
in z.B. /etc/init.d/hm-mod-rpi-pcb die Module beim Start laden
jetzt noch die Devices in den Kontainer:
lxc-device -n yahm add /dev/bcm2835-raw-uart
lxc-device -n yahm add /dev/eq3loop
in yahm in /etc/config/multimacd.conf das richtige device eintragen:
Coprocessor Device Path = /dev/bcm2835-raw-uart
reboot
im host system und im yahm das device /dev/ttyS0 entfernen
jetzt im yahm den multimacd starten. Es werden die devices mmd_bidcos und ttyS0 (243,[12]) angelegt. Diese auch in den Kontainer linken:
lxc-device -n yahm add /dev/mmd_bidcos
lxc-device -n yahm add /dev/ttyS0
wenn der multimacd sich beendet ist sicher noch die V1.4.1 auf dem Modul. Dann dieses auf 2.2.1 im yahm upgraden:
mkdir /firmware/HM-MOD-UART
cd /firmware/HM-MOD-UART
wget --no-check-certificate https://github.com/eq-3/occu/raw/master/firmware/HM-MOD-UART/dualcopro_si1002_update_blhm.eq3
wget --no-check-certificate https://github.com/eq-3/occu/raw/master/firmware/HM-MOD-UART/fwmap
in fwmap die 2.2.1 enablen und dann das upgrade durchführen:
eq3configcmd update-coprocessor -p /dev/bcm2835-raw-uart -t HM-MOD-UART -u -c -d /firmware/HM-MOD-UART
in der Interfaces.xml muss natürlich das HmIP drin sein.
Gruß
Christian
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Bei mir hat all dies nicht geholfen. Ich bekomme immer noch "BidCos-RF Anlernmodus konnte nicht aktiviert werden." Auszug aus dem logfile |
|
Also bei mir scheint es funktioniert zu haben. Wann könnte man mit einer Fertigstellung des Homematic-IP Moduls für YAHM rechnen @leonsio |
|
Ich tippe auf Mitte März
Werde nächstes ccu Release abwarten und alles zusammen rausbringen.
Davor muss ich aber einiges anpassen
Mit freundlichen Grüßen
Leo
… Am 25.02.2017 um 19:55 schrieb Markus M. ***@***.***>:
Also bei mir scheint es funktioniert zu haben.
Die Devices sind da und der multimacd läuft.
Hab leider keine IP Geräte um diese zu testen.
Wann könnte man mit einer Fertigstellung des Homematic-IP Moduls für YAHM rechnen @leonsio
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
habe gerade den test mit 4.9.x branch gemacht und da scheint es nicht mehr zu gehen make -C /lib/modules/4.9.13-v7+/build M=/tmp/kernel-modules/bcm2835_raw_uart modules
make[1]: Entering directory '/root/linux-883de20e54e16f89a878c9957fd265e352ebf5c3'
CC [M] /tmp/kernel-modules/bcm2835_raw_uart/bcm2835_raw_uart.o
/tmp/kernel-modules/bcm2835_raw_uart/bcm2835_raw_uart.c:55:60: fatal error: ../arch/arm/mach-bcm2709/include/mach/platform.h: Datei oder Verzeichnis nicht gefunden
#include <../arch/arm/mach-bcm2709/include/mach/platform.h>
^
compilation terminated.
scripts/Makefile.build:299: recipe for target '/tmp/kernel-modules/bcm2835_raw_uart/bcm2835_raw_uart.o' failed
make[2]: *** [/tmp/kernel-modules/bcm2835_raw_uart/bcm2835_raw_uart.o] Error 1
Makefile:1490: recipe for target '_module_/tmp/kernel-modules/bcm2835_raw_uart' failed
make[1]: *** [_module_/tmp/kernel-modules/bcm2835_raw_uart] Error 2
make[1]: Leaving directory '/root/linux-883de20e54e16f89a878c9957fd265e352ebf5c3'
Makefile:4: recipe for target 'all' failed
make: *** [all] Error 2kann jetzt nicht beurteilen, ob es an den source liegt dass die Platform.h fehlt, oder der Tree generell angepasst wurde |
|
@leonsio Das ist mitunter der Grund wieso RaspberryMatic selbst noch bei Kernel 4.4 ist. Ich denke es führt über kurz/lang kein Weg dran vorbei die Ressourcen-abhängigen Dinge in dem bcm-Kernel modul in ein DeviceTree Overlay zu verwandeln (siehe jens-maus/RaspberryMatic#38) |
|
mit paar kleinen Hacks habe ich das Modul unter 4.9 kompiliert
das Kompilieren ist erfolgreich verlaufen und das Device erscheint unter /dev mal sehen ob alles auch weiterhin funktioniert ;) |
|
Only a hint, maybe usefull for further investigations on bmc2835... Kody on Raspberry Pi3 uses Kernel 4.10.9 (12th of april 2017) including on board wifi on a pi3. http://forum.kodi.tv/showthread.php?tid=298461 I dont know if they use a different driver setup becaus they have a different bootloader ? |
|
wollte nur berichten, dass ich es auch unter YAHM zum laufen gebraucht habe, mit 4.4 und 4.9er Kernel. |
Wenn ich das richtig gehört/verstanden habe benötigt die 2.17 Firmware noch einen speziellen low-latency tty-Treiber damit crRFD/multimacd funktioniert? Ist das richtig? Wenn ja - ist dieser Treiber schon hier im Repo?
The text was updated successfully, but these errors were encountered: