4

好吧，这对我来说真的很奇怪。我有一个模拟的 CAN 总线驱动程序，它是一个 Linux 内核模块。然后我有一个在用户空间运行的测试应用程序，它通过打开文件描述符和发送ioctl()消息来访问驱动程序。

现在 CAN 总线驱动程序只是我一直采用的在 x86 平台上运行的东西（它在我们的嵌入式 Coldfire 系统上运行）。在嵌入式系统上，它必须使用request_mem_region()/ioremap()才能访问内存 I/O 区域，我不需要这样做，但我想尽可能多地保持代码通用。

以下是一些有用的定义：

#define MCF_MBAR    0x10000000

extern unsigned int Base[];
extern unsigned int can_range[];

  //This is the CAN registers on coldfire, just unused on my x86 desktop
Base[minor] = (MCF_MBAR + 0x1c0000); 
can_range[minor] = 0x180;

然后在初始化期间我们这样做：

if(NULL == request_mem_region(Base[minor], can_range[minor], "CAN-IO")) {
    return -EBUSY;
}

can_base[minor] = ioremap(Base[minor], can_range[minor]);

现在，如果我理解正确的话……我们在这里所做的只是请求保留一系列未分配的内存地址，如果我们成功，让我们可以访问它们。

我通过以下方式检查了当前映射的地址cat /proc/iomem：

00000000-0000ffff : reserved
00010000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c8fff : Video ROM
000e2000-000e6fff : Adapter ROM
000f0000-000fffff : reserved
000f0000-000fffff : System ROM
00100000-1ffeffff : System RAM
00200000-0071038b : Kernel code
0071038c-00ad8a7f : Kernel data
00b58000-00c52fff : Kernel bss
                          <--  101C0000-101C0180 : This is where I'd be mapping memory
1fff0000-1fffffff : ACPI Tables
e0000000-e0ffffff : 0000:00:02.0
e0000000-e0bfffff : vesafb
f0000000-f001ffff : 0000:00:03.0
f0000000-f001ffff : e1000
f0400000-f07fffff : 0000:00:04.0
f0400000-f07fffff : vboxguest
f0800000-f0803fff : 0000:00:04.0
f0804000-f0804fff : 0000:00:06.0
f0804000-f0804fff : ohci_hcd
f0806000-f0807fff : 0000:00:0d.0
f0806000-f0807fff : ahci
fee00000-fee00fff : Local APIC
fffc0000-ffffffff : reserved

看起来没有什么东西在使用那个内存，所以我想我在这里还可以。所以我成功地加载了我的内核模块，去运行我的测试程序并且它失败了，再次运行它并且它可以工作。每次在新加载后运行它，它都会失败......第二次，第三次，第 n 次，它会工作：

mike@linux-4puc:~> ./a.out 
  Starting driver test
  Error 'Device or resource busy' opening CAN device
mike@linux-4puc:~> ./a.out 
  Starting driver test
  We opened successfully

这是我非常简单的用户空间程序的一部分：

int fd;
char* dev = "/dev/can0";

printf("Starting driver test\n");

if ((fd = open(dev, O_RDWR)) < 0) {
    printf("Error '%s' opening CAN device", strerror(errno));
    close(fd);
    return -1;
}

关于为什么会发生这种情况的任何想法？如果我request_mem_region()从驱动程序中删除代码一切正常，所以我认为我只是在做一些愚蠢的事情......但为什么它会以它的方式失败？

4

1 回答 1

2

我有点惊讶这对你有用。request_mem_region()传递的值在0x101C0000系统 RAM 的物理地址范围内，0x00100000: 0x1ffeffff。我猜想（初始）错误返回表明内核已经将此物理内存区域安装到其内存池中。当驱动程序错误退出（或模块卸载时）时，它是否会尝试进行适当的清理和调用release_mem_region()，这可能会成功request_mem_region()实现下一次复飞？

通常，您会提供一个未request_mem_region()使用的地址范围（即内核当前未知），因为驱动程序正在使该物理地址范围“可用”（即声明一个物理地址范围以映射到虚拟地址）空间）。

如果你使用类似的东西会发生什么

#define MCF_MBAR    0x90000000

假设物理地址空间真的没有使用？

顺便说一句，如果您的驱动程序release_mem_region()在第一次使用后调用，那么驱动程序有一个错误。驱动程序应该只释放它实际获得的资源。如果request_mem_region()返回错误，则永远不会获取内存资源。因此没有理由调用release_mem_region()（并且驱动程序总是会在 期间得到分配错误_init()）。如果您检查一些正常运行的 Linux 设备驱动程序，您可能会发现精心设计的错误退出方案（使用goto语句）来解开例程中分配的资源，并在代码_init()中释放之前进行有效性检查。_exit()

于 2012-09-24T02:00:07.850 回答