| Summary: | DAHLIN-00352: Astribank (xpp) may fail if loaded from initrd (dracut) | ||
| Reporter: | Tzafrir Cohen (tzafrir) | Labels: | |
| Date Opened: | 2017-02-13 09:04:15.000-0600 | Date Closed: | 2019-06-04 07:43:50 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Astribank (xpp) |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | A system that uses dracut to create the initramfs (e.g.: Centos 7) and has an Astribank | Attachments: | |
| Description: | Error message in question: xpp-related error message (xpp-Error) regarding /usr/share/dahdi/init_card_<n>_30 that has failed (e.g.: <n> = 4).
The Astribank (xpp) kernel modules use a rather non-standard hardware initialization code: part of it is a userspace script (/usr/share/dahdi/init_card_<m>_<n> where m is the module type, e.g. 4 for PRI, and <n> is the protocol version, which has been 30 for quite some time). Dracut is a program that creates an initramfs: an initial filesystem that the kernel can load in order to load the real root filesystem. In order to do that automatically without hand-crafting it copies all the kernel modules that are currently loaded. Thus if you are on e.g. on a Centos 7 system, have an Astribank connected to it (and properly configured) on and have upgraded your kernel, dracut is being run. It will copy the drivers of the Astribank. On the next boot, xpp_usb.ko will get loaded from the initrd. xpp_usb.ko is the module that gets loaded automatically when an Astribank is detected on the USB bus. However the initialization of the Astribanks from the root filesystem may fail if the root filesystem is not yet available by the time they are called. One command to test: {code} lsinitrd | grep xpp_usb {code} If it gives an output, your initrd has the module xpp_usb. A workaround, in case you have this issue: {code} echo 'omit_drivers+=" xpp_usb "' >/etc/dracut.conf.d/dahdi.conf dracut --force {code} | ||
| Comments: | By: Tzafrir Cohen (tzafrir) 2017-03-22 07:16:04.446-0500 From further testing, I believe that the early load of xpp_usb is the only issue. For instance, dahdi device files are generated under /dev/dahdi and anything else that should be triggered by udev events works just fine. By: Keith Morgan (kmorgan) 2019-06-04 07:43:50.906-0500 echo 'omit_drivers+=" xpp_usb "' >/etc/dracut.conf.d/dahdi.conf dracut --force | ||