- 24 Mar, 2022 10 commits
-
-
Raptor Engineering Development Team authored
The OpenVox A1610P/A1610E/A2410P/A2410E series cards all appear to share a design flaw, where wild DMA reads are occassionally emitted from the card. We suspect this design flaw is related to setup timing for the address bus inside the FPGA PCI controller not being met, as it seems temperature dependent and is largely, if not completely, eliminated by ensuring the upper 14 address bits of the PCI bus are never set and forcing the link speed to 2.5GT/s. As all wild DMA, even wild DMA read, is caught by the advanced PCIe controllers on high availability platforms (mostly OpenPOWER, such as Talos II / Blackbird), these cards will regularly drop offline due to the PCIe interface freezing and invoking the EEH handler. Since recovery from this state without a full reload of Asterisk and DAHDI, along with the driver module, is not guaranteed, the wild DMA presents a significant problem for high availability analog PBX servers. For now, work around the broken hardware by setting a DMA mask of 14 bits. Should OpenVox fix the problem in future hardware / firmware revisions, the DMA mask can be reset to the standard 32 bits for this type of PCI device.
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
The voice card generates an interrupt every 1ms, effectively operating in real time. Since migrating the IRQ between CPUs can, in some cases, cause the card to lose sync due to the added delay from migration, lock the interrupt to CPU0 for now.
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
Add initial EEH fast recovery support
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
This is required to work around presumably bad card-side firmware randomly (hours/days/weeks) performing bad DMA writes to the host (!) Example PHB fence event: [53811.103878] EEH: Recovering PHB#1-PE#fc [53811.103904] EEH: PE location: UOPWR.D100022-Node0-SLOT1 PCIE 4.0 X16, PHB location: N/A [53811.103917] EEH: Frozen PHB#1-PE#fc detected [53811.103942] EEH: Call Trace: [53811.103968] EEH: [000000009c27f02d] __eeh_send_failure_event+0x78/0x150 [53811.103997] EEH: [000000009006781a] eeh_dev_check_failure+0x380/0x670 [53811.104030] EEH: [00000000ebe9b5df] __opvx_a24xx_getcreg+0x7c/0xb0 [opvxa24xx] [53811.104073] EEH: [000000005a792683] interrupt_onecard_handler+0x80/0xdc0 [opvxa24xx] [53811.104115] EEH: [00000000903815aa] a24xx_interrupt+0xe8/0x120 [opvxa24xx] [53811.104159] EEH: [0000000061324081] __handle_irq_event_percpu+0x11c/0x4b0 [53811.104203] EEH: [000000008d7d81ec] handle_irq_event_percpu+0x38/0x90 [53811.104244] EEH: [0000000078120288] handle_irq_event+0x60/0xa0 [53811.104286] EEH: [000000008b3623f1] handle_fasteoi_irq+0xd4/0x270 [53811.104318] EEH: [0000000042e6cb54] generic_handle_irq+0x54/0x80 [53811.104366] EEH: [0000000071e8585e] __do_irq+0xa0/0x380 [53811.104399] EEH: [00000000b76ddee5] __do_IRQ+0x9c/0x130 [53811.104440] EEH: [00000000aa5e1b3f] 0xc000000004373b10 [53811.104474] EEH: [000000006d701fc8] do_IRQ+0xfc/0x1d0 [53811.104524] EEH: [0000000070ff629f] replay_soft_interrupts+0x1c4/0x320 [53811.104555] EEH: [0000000095e31904] arch_local_irq_restore+0x1e4/0x250 [53811.104597] EEH: [0000000047c9e272] cpuidle_enter_state+0x158/0x720 [53811.104639] EEH: [00000000904e539f] cpuidle_enter+0x50/0x70 [53811.104680] EEH: [00000000b5de9adb] call_cpuidle+0x4c/0x90 [53811.104721] EEH: [000000008d8e2164] do_idle+0x320/0x3a0 [53811.104761] EEH: [00000000d680deba] cpu_startup_entry+0x3c/0x50 [53811.104784] EEH: [000000006146f980] start_secondary+0x27c/0x2d0 [53811.104820] EEH: [00000000cb4eb9c4] start_secondary_prolog+0x10/0x14 [53811.104849] EEH: This PCI device has failed 2 times in the last hour and will be permanently disabled after 5 failures. [53811.104902] EEH: Notify device drivers to shutdown [53811.104918] EEH: Beginning: 'error_detected(IO frozen)' [53811.104931] PCI 0001:02:00.0#00fc: EEH: driver not EEH aware [53811.104935] EEH: Finished:'error_detected(IO frozen)' with aggregate recovery state:'none' [53811.104958] EEH: Collect temporary log [53811.104988] EEH: of node=0001:02:00.0 [53811.104999] EEH: PCI device/vendor: 16101b74 [53811.105011] EEH: PCI cmd/status register: 04080146 [53811.105020] PHB4 PHB#1 Diag-data (Version: 1) [53811.105030] brdgCtl: 00000002 [53811.105038] RootSts: 00060000 00402000 20110008 00100107 00000800 [53811.105049] PhbSts: 0000001c00000000 0000001c00000000 [53811.105059] Lem: 0000000100000080 0000000000000000 0000000000000080 [53811.105070] PhbErr: 0000028000000000 0000020000000000 2148000098000240 a008400000000000 [53811.105082] RxeTceErr: 6000000000000000 2000000000000000 c0000000000000fc 0000000000000000 [53811.105095] PblErr: 0000000000020000 0000000000020000 0000000000000000 0000000000000000 [53811.105107] RegbErr: 0000004000000000 0000004000000000 8800003c00000000 0000000000000000 [53811.105120] PE[0fc] A/B: 8300b03800000000 8000000000000000 [53811.105130] EEH: Reset with hotplug activity Decoded PEST A/B: Transaction type: DMA Read Response Invalid MMIO Address TCE Page Fault TCE Access Fault LEM Bit Number 56 Requestor 00:0.0 MSI Data 0x0000 Fault Address = 0x0000000000000000
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
-
Raptor Engineering Development Team authored
From GIT hash 1129c666
-
- 12 Mar, 2022 1 commit
-
-
Harald Welte authored
If one of the isochronous or the interrupt EP URB cannot be submitted, we should clean-up properly and avoid hanging the dahdi_cfg process at 100% CPU itilization in an un-killable state. Closes: OS#5477 (https://osmocom.org/issues/5477) Change-Id: Ie6f7f11a64fae0d8c2b7c8ae90df886f2eb8f0c2
-
- 22 Feb, 2022 1 commit
-
-
Harald Welte authored
There's not really any reason to disable those, from what I can tell. Change-Id: Ib03074062ada7b6da485afac53b1550d31f1a5ca
-
- 21 Feb, 2022 2 commits
-
-
Tobias Mädel authored
Change-Id: I54d3000d4535b9279f53a8c30870e897bdcf0f91
-
Tobias Mädel authored
This ports the current zaphfc driver from the Debian bullseye patchset. Change-Id: Ifd09d82ea2b6d6245207609da849350db45d91f6
-
- 08 Feb, 2022 2 commits
-
-
Harald Welte authored
* ability to read GPSDO related bits via sysfs and ioctl * ability to set GPSDO mode via sysfs * show firmware build during driver start and expose it to sysfs Change-Id: I7bc7daa4738b1db37fdd67945d7e976e2581b417
-
Harald Welte authored
git revision cac342af6bccc9820a8617f900afaf663ad608ed of https://git.osmocom.org/osmo-e1-hardware Change-Id: I1423531470a1c9165d713108fb6a87ff47ff6e29
-
- 07 Feb, 2022 1 commit
-
-
Oliver Smith authored
Build the kernel module against a given linux tree. This script will be used in CI at jenkins.osmocom.org. Related: OS#5407 Depends: docker-playground Id72d19ad08681cd7cb3194de2226292f19e96df5 Change-Id: I904ab66a1ecd72492642ac2cc4cb102c7283c590
-
- 23 Jan, 2022 1 commit
-
-
Shaun Ruffell authored
Kernel version 5.8, in commit "modpost: use read_text_file() and get_line() for reading text files" [1] made it an error if the .o.cmd file is missing. However, this file is not generated for shipped .o files. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70f30cfe5b892fcb7f98e7df72ed6ccfe3225628Signed-off-by:
Shaun Ruffell <sruffell@sruffell.net> Change-Id: I06d201bcd07b35cb41c8c4a8467bcad6471c431a
-
- 22 Jan, 2022 1 commit
-
-
Harald Welte authored
This seems to be the kernel default for CTRL request timeout, let's use it here. Change-Id: I7b7c1a2b13f61372e839e34a376e66c91190bdb3
-
- 20 Jan, 2022 1 commit
-
-
Jan Engelhardt authored
Change-Id: I36438e35bb99325e1ac86b68c1746670a9851e4a
-
- 13 Jan, 2022 2 commits
-
-
Harald Welte authored
If an already-active line gets reconfigured, we implement this by a shutdown followed by a startup. However, the startup could fail, which should make the spanconfig return the error code.
-
Harald Welte authored
This is what happens if there is insufficient isochronous USB bandwidth to open a port: The STARTUP ioctl fails. However, as the prior SPANCONFIG ioctl succeeds, the line apears up with no alarms. So let's set the NOTOPEN alarm whenever there are errors in STARTUP, to give a clear indication to the user the port could not be opened.
-
- 12 Jan, 2022 1 commit
-
-
Harald Welte authored
find_altsetting_on() must not only find an altsetting with no zero-sized endpoints, but must also make sure there actually are endpoints. This enables compatibility with icE1usb firmware >= 0.1-43-g9674436
-
- 10 Jan, 2022 1 commit
-
-
Harald Welte authored
The XAIS bit to check in the FRS0 register is at 0x40, and not 0x4. If only the original authors had the wisdom to use #defines for those bits, and re-used those bits across the drivers (wct4xxp, wcte43x and wcte13xp get this right!).
-
- 02 Jan, 2022 1 commit
-
-
Harald Welte authored
In osmo-e1-hardware.git Change-Id Ic4f57cf79bd32cf75f81ef3073cb8d4a2d1857d8 the icE1usb firmware gained support for reporting the E1_ERR_F_RAI flag via USB interrupt transfers. Make use of that to report YELLOW alarm via the usual DAHDI alarms infrastructure.
-
- 01 Jan, 2022 3 commits
-
-
Harald Welte authored
-
Harald Welte authored
This adds support of configuring the icE1usb TX configuration via the standard DAHDI mechanisms.
-
Harald Welte authored
We get loss-of-framing and loss-of-signal notification via USB interrupt transfers. Let's make use of this information to tell the DAHDI core [and ultimately the user] about this.
-
- 31 Dec, 2021 2 commits
-
-
Harald Welte authored
Copy from firmware source code repo at https://git.osmocom.org/osmo-e1-hardware/tree/firmware/ice40-riscv/icE1usb/ice1usb_proto.h as of d376b2e852fbf26a60ac4d6f66e54bb85f0b7204
-
Harald Welte authored
Before this commit, we used to "lock up" the E1 span on every subsequent span re-configuration from userspace. This typically happens when the user calls the `dahdi_cfg` userspace utility. As normally this only happens once at system start-up, this bug was only discovered now. Closes: OS#5379
-
- 29 Nov, 2021 10 commits
-
-
Harald Welte authored
The Osmocom icE1usb is a modern, software-defined open hardware and open source firmware design for a USB E1 interface. You can find more information at https://osmocom.org/projects/e1-t1-adapter/wiki/IcE1usb The hardware design can be found at https://git.osmocom.org/osmo-e1-hardware The FPGA gateware and associated embedded firmware is hosted in the same git repository. Some parts are in submodules (be sure to use recursive clone) This DAHDI driver allows t lothe use of the icE1usb just like any other E1/PRI interface device supported by DAHDI. When using this DAHDI driver, osmo-e1d most not be used. The DAHDI driver is a replacement / alternative for osmo-e1d.
-
Harald Welte authored
For automatic testing scenarios, it is very useful to be able to artificially create line alarms. This allows testing of the whole stack through DAHDI itself, DAHDI-interfaces in applications and actual applications. It introduces a new DAHDI_SIMULATE_ALARM ioctl() whcih has to be issued on /dev/dahdi/ctl and which can be used to set or remove any simulated alarms on the given span.
-
Harald Welte authored
It recently occurre to me that for some strange reason the line/link status of the E1 span was not reflected in the network device link status. This is odd and leads to strange behavior. In general, it is assumed that a net_device only exhibits LOWER_UP if there actually is a physical connection. If you disconnect an ethernet cable, LOWER_UP will be gone. Same should happen on DAHDI_NET devices.
-
Harald Welte authored
-
Harald Welte authored
-
Harald Welte authored
This reverts commit 36974503.
-
Harald Welte authored
-
Harald Welte authored
This reverts commit 3748456d, which removed a driver simply becuase Digium proclaimed they didn't sell a card in 10 years. That does *not* mean nobody is using those anymore. I wish there was more of a community maitaining the DAHDI drivers.
-
Harald Welte authored
-
Harald Welte authored
Especially for automatic testing it is quite useful to have virtual DAHDI spans with a loopback between them.
-