[英]Debian: Module can-dev loaded with load-modules.conf does not work until I reload it manually
I have a slight problem with using can bus on a raspberry pi with Debian 64 bit running on it.我在运行 Debian 64 位的树莓派上使用 can 总线时遇到了一点问题。
My /etc/modules-load.d/modules.conf looks like this:我的 /etc/modules-load.d/modules.conf 看起来像这样:
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
ixxat_usb2can
can-dev
can-raw
Right after startup and sshing to the machine, I have the modules loaded:在启动并 sshing 到机器之后,我已经加载了模块:
~/$ lsmod | grep can
can_raw 28672 0
can 28672 1 can_raw
ixxat_usb2can 28672 0
can_dev 28672 1 ixxat_usb2can
usbcore 266240 5 xhci_hcd,ixxat_usb2can,dwc2,brcmfmac,xhci_pci
The can bus seems to be ready and the interface can0 is up: can 总线似乎已经准备好了,并且接口 can0 已启动:
~/$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e4:5f:01:2e:2e:72 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.77/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2a02:810b:43c0:539c:e65f:1ff:fe2e:2e72/64 scope global dynamic mngtmpaddr
valid_lft 86398sec preferred_lft 43198sec
inet6 fe80::e65f:1ff:fe2e:2e72/64 scope link
valid_lft forever preferred_lft forever
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
link/can
4: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
link/can
5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether e4:5f:01:2e:2e:73 brd ff:ff:ff:ff:ff:ff
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:6b:e0:11:18 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
if I try to access a motor device connected via can adapter on interface can0, it does not work, I get an error code from the motor control library which is, sadly, not documented, but it happens while trying to find the can device.如果我尝试访问通过接口 can0 上的 can 适配器连接的电机设备,它不起作用,我从电机控制库中得到一个错误代码,遗憾的是,该代码没有记录在案,但它在尝试查找 can 设备时发生。
What I think is weird: I only need to reload the can-dev module to make it work.我认为很奇怪:我只需要重新加载 can-dev 模块即可使其工作。 Afterwards, there is no change to lsmod, but I can find the device and the motor moves just as I wish to:
之后,lsmod 没有任何变化,但我可以找到设备并且电机按照我的意愿移动:
~/$ sudo /sbin/modprobe can-dev
~/$ lsmod | grep can
can_raw 28672 0
can 28672 1 can_raw
ixxat_usb2can 28672 0
can_dev 28672 1 ixxat_usb2can
usbcore 266240 5 xhci_hcd,ixxat_usb2can,dwc2,brcmfmac,xhci_pci
So my basic question is: What happens here?所以我的基本问题是:这里发生了什么? Am I missing anything?
我错过了什么吗? Thanks in advance!
提前致谢!
I just figured it out, kind of, so in case someone runs into any problem like this:我只是想通了,有点,所以万一有人遇到这样的问题:
I have never looked at interface can1
, because I don't use it.我从未看过接口
can1
,因为我不使用它。 My usb to can dongle has this interface, but it is open ended, nothing is connected there, so it was way out of my scope.我的 usb to can dongle 有这个接口,但它是开放式的,没有任何连接,所以它是我的 scope 的出路。 But having a closer look at
ip a
right after start and then again after loading the can-dev
-module a second time manually reveals that it has impact on the state of interface can1
.但是仔细查看
ip a
在启动后,然后在第二次手动加载can-dev
模块后再次显示它对接口 can1 的can1
。
Before manually loading can-dev:在手动加载 can-dev 之前:
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
link/can
4: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
link/can
and afterwards:之后:
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
link/can
4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
link/can
So, it seems that the state of can1
is crucial for my device on can0
to work properly.因此,can1 的
can1
似乎对于我在can0
上的设备正常工作至关重要。 All I did then was to create a file called can1
in my /etc/network/interfaces.d
which looks the following and which gets can1 up on startup:我所做的只是在我的
/etc/network/interfaces.d
中创建一个名为can1
的文件,该文件如下所示,并且在启动时会启动 can1:
auto can1
iface can1 inet manual
pre-up /sbin/ip link set can1 type can bitrate 1000000
up /sbin/ip link set up can1 && /sbin/modprobe can-dev
down /sbin/ip link set down can1
I am not sure if loading of the module in the "up" part of that configuration is neccessary here and - more important - has any disadvantages.我不确定是否需要在该配置的“向上”部分加载模块,并且 - 更重要的是 - 有任何缺点。 If someone knows about that stuff better than me (and I am sure most of you linux people out there do), please let me know.
如果有人比我更了解这些东西(我相信你们中的大多数 linux 人都知道),请告诉我。
In the end, the can bus works as expected without executing additional commands, right from startup.最后,can 总线从启动开始就按预期工作,无需执行额外的命令。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.