I'm trying to run dxdiag or any other DX9 game from bumblebee+wine and no luck. These games works well without bumblebee in integrated graphic card. And no wine soft works well with bumblebee.
primusrun
$ primusrun bash
$ wine dxdiag
primus: warning: recreating incompatible pbuffer
primus: warning: recreating incompatible pbuffer
$
syslog output:
rtkit-daemon[2489]: Successfully made thread 23036 of process 23036 (n/a) owned by '1000' RT at priority 3.
rtkit-daemon[2489]: Supervising 1 threads of 1 processes of 1 users.
kernel: [147774.078061] bbswitch: enabling discrete graphics
kernel: [147774.221739] pci 0000:01:00.0: power state changed by ACPI to D0
kernel: [147774.245670] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=none,decodes=none:owns=none
kernel: [147774.245900] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 304.88 Wed Mar 27 14:26:46 PDT 2013
acpid: client 23009[0:1002] has disconnected
acpid: client 23009[0:1002] has disconnected
acpid: client connected from 23066[0:1002]
acpid: 1 client rule loaded
acpid: client connected from 23066[0:1002]
acpid: 1 client rule loaded
bumblebeed[11391]: [XORG] (WW) NVIDIA(0): Unable to get display device for DPI computation.
rtkit-daemon[2489]: Successfully made thread 23071 of process 23033 (n/a) owned by '1000' RT at priority 2.
rtkit-daemon[2489]: Supervising 2 threads of 2 processes of 1 users.
kernel: [147778.018119] bbswitch: disabling discrete graphics
kernel: [147778.030858] pci 0000:01:00.0: Refused to change power state, currently in D0
kernel: [147778.030896] pci 0000:01:00.0: power state changed by ACPI to D3cold
optirun has similar result:
$ optirun bash
$ wine dxdiag
[VGL] NOTICE: Pixel format of 2D X server does not match pixel format of
[VGL] Pbuffer. Disabling PBO readback.
$
The syslog has the same error with optirun:
bumblebeed[11391]: [XORG] (WW) NVIDIA(0): Unable to get display device for DPI computation.
Any help? thank you!
This may or may not help, but try installing the primus-libs-ia32 package, it may be a 32 bit application you're trying to run (if you're on a 64 bit system, this could be the problem).
Related
I'm having some difficulty configuring U-Boot, in particular setting it up so that it can load from an SD card, but access its Environment from QSPI Flash.
First of all, is this even possible? Can the U-Boot environment be stored in a different location from where U-Boot was loaded?
Currently, I have a U-Boot image running from QSPI Flash on a Xilinx MPSoC ARM64 platform. I'm using Xilinx
PetaLinux however I think I understand how this configures U-Boot "under the hood" so I'll try to refer to
uboot.cfg as much as I can.
Along with all the defaults, I have set:
#define CONFIG_ENV_OFFSET 0x2E00000
#define CONFIG_ENV_OVERWRITE 1
#define CONFIG_CMD_ERASEENV 1
On this particular platform, there is a physical switch to switch the Xilinx first-stage bootloader (and ARM
Trusted Firmware) between QSPI Flash and SD card modes. This platform also requires a so-called "BOOT.BIN", which
is an aggregation of the u-boot binary, the Xilinx FSBL, ARM Trusted Firmware, an FPGA image and
other things, to be written to QSPI Flash, which I have done. This is all working correctly, and the serial console
looks like this at reset or power-on:
Xilinx Zynq MP First Stage Boot Loader
Release 2021.2 Oct 13 2021 - 07:15:53
NOTICE: BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE: BL31: Built : 07:41:24, Oct 13 2021
U-Boot 2021.01 (Oct 12 2021 - 09:28:42 +0000)
CPU: ZynqMP
Silicon: v3
Model: ZynqMP ZCU208 RevA
Board: Xilinx ZynqMP
DRAM: 4 GiB
PMUFW: v1.1
EL Level: EL2
Chip ID: zu48dr
NAND: 0 MiB
MMC: mmc#ff170000: 0
Loading Environment from SPIFlash... SF: Detected mt25qu02g with page size 512 Bytes, erase size 128 KiB, total 512 MiB
...
As you can see, U-Boot loads from QSPI Flash and the Environment is also loaded from QSPI Flash. All good.
What I want to do is modify the system so that the First Stage Boot Loader loads U-Boot from the SD card. In my config I
already have CONFIG_ENV_IS_IN_FAT set to 1. When I copy BOOT.BIN to the first, FAT partition on an SD card, and set my
platform's boot mode to "SD Card" via the physical switch, the unit loads U-Boot from the SD card successfully, and the
serial console shows output similar to the above but with:
Loading Environment from FAT... *** Warning - bad CRC, using default environment
It works, although this warning is expected because there is no Environment saved on the SD card yet.
It does show that the SD card is being checked for the Environment though, so that's good.
Note that this is the same build that I used for the QSPI flash boot earlier, but it's looking for the config on FAT, so I'm currently under the impression that
U-Boot only looks for its Environment based on where it was loaded from, even if other locations are enabled. I also tried in QEMU and it seemed to think that the config came from "nowhere", but that may be a distraction.
The issue is that I would like to configure U-Boot to be loaded from the SD card (for ease of upgrade / development), but to use QSPI for its Environment,
so that I can store persistent U-Boot configuration on the board itself.
In particular, the MAC address for the board is not readable via software so must be manually configured in U-Boot, and I'd like that to follow around the board, not the SD card. There are a few other options I'd like to set per-board also.
According to the U-Boot documentation I've read, disabling FAT as the default should be achievable by unsetting the
following in u-boot.cfg:
CONFIG_ENV_IS_IN_FAT
CONFIG_SYS_MMC_ENV_DEV
CONFIG_ENV_FAT_DEVICE_AND_PART
CONFIG_ENV_IS_IN_FAT
CONFIG_ENV_FAT_FILE
CONFIG_SYS_MMC_ENV_PART
CONFIG_ENV_FAT_INTERFACE
Performing the same installation steps as above, to have this new U-Boot loaded from the SD card, results in the
following output:
Xilinx Zynq MP First Stage Boot Loader
Release 2021.2 Oct 13 2021 - 07:15:53
NOTICE: BL31: v2.4(release):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE: BL31: Built : 07:41:24, Oct 13 2021
And that's it! No more output. There is an LED on the board that goes from red to green, which I think indicates that
the FPGA image within BOOT.BIN has been loaded into the gate array successfully, so I think the earlier boot loader
has found BOOT.BIN. I have no reason therefore to think that U-Boot has not also been loaded, but if it has, it is
generating no output. I tried increasing the debug level of U-Boot to 7 (DEBUG) in the hope of seeing something
from U-Boot, but that makes no difference. It's also not booting Linux, which would normally happen next.
Can anyone shed any light on why making this change might result in this behaviour? Is there some other
configuration option I need to set to ensure that U-Boot can run from the SD card when CONFIG_ENV_IS_IN_FAT
and friends are not set? Or perhaps I can keep CONFIG_ENV_IS_IN_FAT etc. and there's some other way to instruct
U-Boot to use the QSPI Flash for its environment, even though it was loaded from SD card?
Note: I've also enabled ATF debugging, which produces the following output, but it still hangs with no sign of U-Boot:
INFO: PSCI Power Domain Map:
INFO: Domain Node : Level 1, parent_node -1, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x0, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x1, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x2, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x3, parent_node 0, State ON (0x0)
Xilinx Zynq MP First Stage Boot Loader
Release 2021.2 Oct 13 2021 - 07:15:53
WARNING: BL31: invalid exception level (3)
NOTICE: BL31: v2.4(debug):xlnx_rebase_v2.4_2021.1_update1-23-g9188496b9
NOTICE: BL31: Built : 07:41:24, Oct 13 2021
INFO: ARM GICv2 driver initialized
INFO: BL31: Initializing runtime services
INFO: BL31: PM Service Init Complete: API v1.1
INFO: BL31: cortex_a53: CPU workaround for 855873 was applied
WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x8000000
INFO: SPSR = 0x3c9
Answering my own question:
I do not know why the console remains blank/dead in this case, but the related code is this function here:
https://github.com/u-boot/u-boot/blob/master/board/xilinx/zynqmp/zynqmp.c#L850
According to this switch statement, when the boot mode is SD_MODE, the case does not consider CONFIG_ENV_IS_IN_SPI_FLASH at all, and therefore the function returns ENVL_NOWHERE when booted from SD with CONFIG_ENV_IS_IN_FAT disabled.
Modifying this function to return ENVL_SPI_FLASH in this case enables U-Boot access to the Environment in the QSPI Flash:
case SD_MODE1:
if (IS_ENABLED(CONFIG_ENV_IS_IN_FAT))
return ENVL_FAT;
if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4))
return ENVL_EXT4;
++ if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
++ return ENVL_SPI_FLASH;
return ENVL_NOWHERE;
I have downloaded asimbench files which provided in the gem5.org website and I have modified the config/common/FSConfig.py with following changes:
def makeArmSystem(..)
..................
self.cf0 = CowIdeDisk(driveID='master')
self.cf2 = CowIdeDisk(driveID='master')
self.cf0.childImage(mdesc.disk())
self.cf2.childImage(disk("sdcard-1g-mxplayer.img"))
#Old platforms have a built-in IDE or CF controller. Default to
#the IDE controller if both exist. New platforms expect the
#storage controller to be added from the config script.
if hasattr(self.realview, "ide"):
#self.realview.ide.disks = [self.cf0]
self.realview.ide.disks = [self.cf0, self.cf2]
elif hasattr(self.realview, "cf_ctrl"):
#self.realview.cf_ctrl.disks = [self.cf0]
self.realview.cf_ctrl.disks = [self.cf0, self.cf2]
else:
self.pci_ide = IdeController(disks=[self.cf0])
pci_devices.append(self.pci_ide
I used this command:
./build/ARM/gem5.opt configs/example/fs.py --mem-size=8192MB
--disk-image=/home/yaz/gem5/full_system_images/disks/ARMv7a-ICS-Android.SMP.Asimbench-v3.img
--kernel=/home/yaz/gem5/full_system_images/binaries/vmlinux.smp.ics.arm.asimbench.2.6.35
--os-type=android-ics --cpu-type=MinorCPU --machine-type=VExpress_GEM5 --script=/home/yaz/gem5/full_system_images/boot/adobe.rcS
warn: CheckedInt already exists in allParams. This may be caused by
the Python 2.7 compatibility layer. warn: Enum already exists in
allParams. This may be caused by the Python 2.7 compatibility layer.
warn: ScopedEnum already exists in allParams. This may be caused by
the Python 2.7 compatibility layer. gem5 Simulator System.
http://gem5.org gem5 is copyrighted software; use the --copyright
option for details. gem5 version 20.0.0.3 gem5 compiled Jul 7 2020
16:17:12 gem5 started Jul 16 2020 04:41:50 gem5 executing on
yazeed-OptiPlex-9010, pid 3367 command line: ./build/ARM/gem5.opt
configs/example/fs.py --mem-size=8192MB
--disk-image=/home/yaz/gem5/full_system_images/disks/ARMv7a-ICS-Android.SMP.Asimbench-v3.img
--kernel=/home/yaz/gem5/full_system_images/binaries/vmlinux.smp.ics.arm.asimbench.2.6.35
--os-type=android-ics --cpu-type=MinorCPU --machine-type=VExpress_GEM5 --script=/home/yaz/gem5/full_system_images/boot/adobe.rcS
Global frequency set at 1000000000000 ticks per second
warn: No dot file generated. Please install pydot to generate the dot file and pdf.
info: kernel located at: /home/yaz/gem5/full_system_images/binaries/vmlinux.smp.ics.arm.asimbench.2.6.35
system.vncserver: Listening for connections on port 5900
system.terminal: Listening for connections on port 3456
system.realview.uart1.device: Listening for connections on port 3457
system.realview.uart2.device: Listening for connections on port 3458
system.realview.uart3.device: Listening for connections on port 3459
0: system.remote_gdb: listening for remote gdb on port 7000 info:
Using bootloader at address 0x80000000
info: Using kernel entry physical address at 0x140008000 warn: DTB file specified, but no
device tree support in kernel
**** REAL SIMULATION ****
warn:Existing EnergyCtrl, but no enabled DVFSHandler found. info: Entering
event queue # 0. Starting simulation...
fatal: Unable to find destination for [0x40008000:0x40008040] on system.iobus
Memory Usage: 8786764 KBytes
Thanks for helping
The problem incident:
Our production system started denying services with an error message "Too many open files in system". Most of the services were affected, including inability to start a new ssh session, or even log in into virtual console from the physical terminal. Luckily, one root ssh session was open, so we could interact with the system (morale: keep one root session always open!). As a side effect, some services (named, dbus-daemon, rsyslogd, avahi-daemon) saturated the CPU (100% load). The system also serves a large directory via NFS to a very busy client which was backing up 50000 small files at the moment. Restarting all kinds of services and programs normalized their CPU behavior, but did not solve the "Too many open files in system" problem.
The suspected cause
Most likely, some program is leaking file handles. Probably the culprit is my tcl program, which also saturated the CPU (not normal). However, killing it did not help, but, most disturbingly, lsof would not reveal large amounts of open files.
Some evidence
We had to reboot, so whatever information was collected is all we have.
root#xeon:~# cat /proc/sys/fs/file-max
205900
root#xeon:~# lsof
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
init 1 root cwd DIR 8,6 4096 2 /
init 1 root rtd DIR 8,6 4096 2 /
init 1 root txt REG 8,6 124704 7979050 /sbin/init
init 1 root mem REG 8,6 42580 5357606 /lib/i386-linux-gnu/libnss_files-2.13.so
init 1 root mem REG 8,6 243400 5357572 /lib/i386-linux-gnu/libdbus-1.so.3.5.4
...
A pretty normal list, definitely not 200K files, more like two hundred.
This is probably, where the problem started:
less /var/log/syslog
Mar 27 06:54:01 xeon CRON[16084]: (CRON) error (grandchild #16090 failed with exit status 1)
Mar 27 06:54:21 xeon kernel: [8848865.426732] VFS: file-max limit 205900 reached
Mar 27 06:54:29 xeon postfix/master[1435]: warning: master_wakeup_timer_event: service pickup(public/pickup): Too many open files in system
Mar 27 06:54:29 xeon kernel: [8848873.611491] VFS: file-max limit 205900 reached
Mar 27 06:54:32 xeon kernel: [8848876.293525] VFS: file-max limit 205900 reached
netstat did not show noticeable anomalies either.
The man pages for ps and top do not indicate an ability to show open file count. Probably the problem will repeat itself after a few months (that was our uptime).
Any ideas on what else can be done to identify the open files?
UPDATE
This question has changed the meaning, after qehgt identified the likely cause.
Apart from the bug in NFS v4 code, I suspect there is a design limitation in Linux and kernel-leaked file handles can NOT be identified. Consequently, the original question transforms into:
"Who is responsible for file handles in the Linux kernel?" and "Where do I post that question?". The 1st answer was helpful, but I am willing to accept a better answer.
Probably the root cause is a bug in NFSv4 implementation: https://stackoverflow.com/a/5205459/280758
They have similar symptoms.
I've been trying to build and boot OpenEmbedded-Core on the evaluation kit for Freescale's ARM i.MX28, using the Freescale ARM layer for OpenEmbedded-Core. Unfortunately, I can't find a basic "Getting Started" guide (though there is a Yocto getting-started guide). Unfortunately, I haven't been able to "get started", to the point of successfully booting to a basic command prompt on the board's debug serial port.
Here is what I've been able to piece together, and as far as I've managed to get so far.
Fetch sources
mkdir -p oe-core/freescale-arm
cd oe-core/freescale-arm
git clone git://git.openembedded.org/openembedded-core oe-core
git clone git://github.com/Freescale/meta-fsl-arm.git
cd oe-core
git clone git://git.openembedded.org/meta-openembedded
git clone git://git.openembedded.org/bitbake bitbake
Set up environment
. ./oe-init-build-env
That puts us in a new sub-directory build and sets certain environment variables.
Edit configuration
Edit the conf/bblayers.conf and local.conf files:
conf/bblayers.conf should have the meta-fls-arm and meta-oe layers added for BBLAYERS. E.g.:
BBLAYERS ?= " \
/home/craigm/oe-core/freescale-arm/oe-core/meta \
/home/craigm/oe-core/freescale-arm/oe-core/meta-openembedded/meta-oe \
${TOPDIR}/../../meta-fsl-arm \
"
In conf/local.conf, I set:
BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 4"
MACHINE = "imx28evk"
Build
bitbake core-image-minimal
I ran this build overnight, and it has completed successfully for me. Output files were in ~/oe-core/freescale-arm/oe-core/build/tmp-eglibc/deploy/images.
There are two boot options that I'd like to try, as described below. Boot from SD card is simpler, but takes quite a long time (~30 min) to write the image to the SD card. Booting from TFTP + NFS is faster, but requires more set-up.
Boot from SD Card
Write image to SD card:
sudo dd if=tmp-eglibc/deploy/images/core-image-minimal-imx28evk.sdcard of=/dev/sdc
It took something like 30 minutes (3.5 GB file). Then I put it in the board's SD card slot 0, and powered-up. It got as far as loading the kernel, then stopped:
U-Boot 2012.04.01-00059-g4e6e824 (Aug 23 2012 - 18:08:54)
Freescale i.MX28 family at 454 MHz
BOOT: SSP SD/MMC #0, 3V3
DRAM: 128 MiB
MMC: MXS MMC: 0
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: FEC0, FEC1
Hit any key to stop autoboot: 0
reading boot.scr
** Unable to read "boot.scr" from mmc 0:2 **
reading uImage
2598200 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-2.6.35.3-11.09.01+yocto-20
Created: 2012-08-23 7:53:40 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2598136 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Boot from TFTP + NFS
First, I tried to write U-Boot onto an SD card:
sudo dd if=tmp-eglibc/deploy/images/u-boot-imx28evk.mxsboot-sdcard of=/dev/sdc
Then I put it in the board's SD card slot 0, and powered-up. But all I got in the debug serial port was:
0x8020a01d
So, I decided to use Freescale's distribution of U-Boot for i.MX28 (from their LTIB distribution) onto an SD card. I set suitable U-Boot parameters for NFS booting with parameters from DHCP.
setenv bootargs console=ttyAMA0,115200n8
setenv bootargs_nfs setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=,v3,tcp fec_mac=${ethaddr}
saveenv
I connected to a DD-WRT router with the following DNSmasq settings:
dhcp-boot=,,192.168.250.106
dhcp-option=17,"192.168.250.106:/home/craigm/rootfs"
On my host PC, I set up a TFTP server to serve the uImage file from ~/oe-core/freescale-arm/oe-core/build/tmp-eglibc/deploy/images/.
I also set up a root NFS server to serve the root file system. I edited /etc/exports to serve /home/craigm/rootfs. I extracted the root file system:
bitbake meta-ide-support
rm -Rf ~/rootfs
runqemu-extract-sdk tmp-eglibc/deploy/images/core-image-minimal-imx28evk.tar.bz2 ~/rootfs
Then I put the U-Boot SD card in the board's SD card slot 0, and powered-up. It got as far as this, then stopped:
...
TCP cubic registered
NET: Registered protocol family 17
can: controller area network core (rev 20090105 abi 8)
NET: Registered protocol family 29
can: raw protocol (rev 20090105)
mxs-rtc mxs-rtc.0: setting system clock to 1970-01-01 00:03:33 UTC (213)
eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
eth1: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1)
Sending DHCP requests .
PHY: 0:00 - Link is Up - 100/Full
., OK
IP-Config: Got DHCP answer from 192.168.250.106, my address is 192.168.250.142
IP-Config: Complete:
device=eth0, addr=192.168.250.142, mask=255.255.255.0, gw=192.168.250.1,
host=192.168.250.142, domain=, nis-domain=(none),
bootserver=192.168.250.106, rootserver=192.168.250.106, rootpath=/home/craigm/rootfs
Looking up port of RPC 100003/3 on 192.168.250.106
Looking up port of RPC 100005/3 on 192.168.250.106
VFS: Mounted root (nfs filesystem) on device 0:15.
Freeing init memory: 160K
I'm not sure if it's running without a serial console, or some other problem. I can ping it on 192.168.250.142, but I can't Telnet or SSH to it.
Questions
Is there any sort of "getting started" guide for OpenEmbedded-Core on Freescale's i.MX28?
Is the Freescale ARM layer really intended for use with OpenEmbedded-Core, Yocto, or what? I don't really understand how those projects relate.
Has anyone else had success booting a minimal image of OpenEmbedded-Core on Freescale's i.MX28? If so, how did your procedure differ from mine?
I'm not sure at this stage whether the problem is just a non-functional serial console, or some other sort of issue. It's hard to diagnose these problems that prevent even getting a basic system running. Any pointers on how to diagnose at this point?
Why would the U-Boot be broken so it can't even boot?
From the boot message it looks like U-boot is working fine. U-boot is not broken.
The following boot message
2598200 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-2.6.35.3-11.09.01+yocto-20
Created: 2012-08-23 7:53:40 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2598136 Bytes = 2.5 MiB
Load Address: 40008000
Entry Point: 40008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
By the above log u-boot has done its job.
"Booting the kernel" is the point where bootloader given the control to the kernel.
I guess the problem might be in kernel image or in memory.
To eliminate the problem of memory, try to check the manual and try to read and write in the RAM using the board's reference manual.
From the boot log RAM looks like has no problem. It has been initialized.
DRAM: 128 MiB
Check if the following message is not causing any problem.
* Warning - bad CRC, using default environment
Check if all the devices have been initialized and nothing is skipped after the bad crc warning.
I'm trying to use a somewhat old DAQ, and had to jump through a few hoops to get an old (circa 2004) device driver for it to compile (DTI-DT340 Linux-DAQ-PCI).
I've gotten to the point where it compiles, I can load the kernel module, it finds the card, and I can create the character devices using mknod.
But I can't seem to open these devices and keep getting errno 19 (ENODEV) 'No such device' when I try to
open("/dev/dt340/0",O_RDWR);
but mknod had no complaints about making it, and it's there:
# ls -l /dev/dt340/
total 0
crw-rw-r-- 1 root staff 250, 0 2009-04-23 11:02 0
crw-rw-r-- 1 root staff 250, 1 2009-04-23 11:02 1
crw-rw-r-- 1 root staff 250, 2 2009-04-23 11:02 2
crw-rw-r-- 1 root staff 250, 3 2009-04-23 11:02 3
Is there something I'm neglecting to do? What might be a reason open fails?
Here's the script I use to load the driver and make the devices.
#!/bin/bash
module="dt340"
device="dt340"
mode="664"
# invoke modprobe with all arguments we were passed
#/sbin/modprobe -t misc -lroot -f -s $module.o $* || exit 1
insmod $module.ko
# remove stale nodes
rm -f /dev/${device}/[0-3]
major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
mkdir -p /dev/${device}
mknod /dev/${device}/0 c $major 0
mknod /dev/${device}/1 c $major 1
mknod /dev/${device}/2 c $major 2
mknod /dev/${device}/3 c $major 3
# give appropriate group/permissions, and change the group
# not all distributions have staff; some have "users" instead
group="staff"
grep '^staff:' /etc/group > /dev/null || group="users"
chgrp $group /dev/${device}/[0-3]
chmod $mode /dev/${device}/[0-3]
Some additional info:
#grep dt340 /proc/devices
250 dt340
# lsmod | grep dt340
dt340 21516 0
# tail /var/log/messages
Apr 23 11:59:26 ve kernel: [ 412.862139] dt340 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Apr 23 11:59:26 ve kernel: [ 412.862362] dt340: In function dt340_init_one:
Apr 23 11:59:26 ve kernel: [ 412.862363] Device DT340 Rev 0x0 detected at address 0xfebf0000
#lspci | grep 340
03:01.0 Multimedia controller: Data Translation DT340
ANSWER: A printk confirmed that the -ENODEV was thrown from inside open(). Following an oldstyle
while ((pdev = pci_find_device(PCI_VENDOR_ID_DTI, PCI_ANY_ID, pdev)))
(which is deprecated), if(!pdev) ends up true, and returns the -ENODEV.
I'm inching closer - I guess I have to work through and update the pci code to use more modern mechanisms...
If the device shows up in /proc/devices, and you're sure you've got the number right in mknod, then the driver itself is refusing the open. The driver can return any error code from open() - including "no such device", which it might if it discovered a problem initialising the hardware.
I'd guess it is a problem in the driver, check the open function.
It shows up in /proc/devices, so all the generic device stuff seems to be ok.
mknod doesn't care if there is an device corresponding to the given major/minor numbers. Are you sure insmod is installing your module? What does lsmod tell you?
I'm unfamiliar with having to add the ".ko" extension. Is that something specific to your device driver?
Check through lspci and make sure hardware is properly initialized. If your system supports hotplug, pci_find_device won't work. The problem with this is a refcnt. The best way to deal and learn is to dissect the API. BOL !!