Добрый день!
Я скомпилировал последние драйвера под линукс в Fedora 11 но при попытке загрузки драйверов я получил kernel panic при этом ldevice.ko грузится а остальные нет. Если интересно пришлю лог загрузки. Подскажите знающие люди что делать.

лог можете прислать, но ждать новой версии можно как Slackware выйдет 13я...

вот лог make
make modules
make -C /lib/modules/2.6.29.1-102.fc11.i686.PAE/build M=/home/dstr modules
make[1]: Entering directory `/usr/src/kernels/2.6.29.1-102.fc11.i686.PAE/'
  CC [M]  /home/dstr/ldevice.o
/home/dstr/ldevice.c: В функции ‘ldev_init’:
/home/dstr/ldevice.c:158: предупреждение: при передаче аргумента 5 ‘device_create’ целое преобразуется в указатель без приведения типа
include/linux/device.h:518: замечание: expected ‘const char *’ but argument is of type ‘int’
  CC [M]  /home/dstr/l760.o
  CC [M]  /home/dstr/ldevpciu.o
  CC [M]  /home/dstr/l791.o
  CC [M]  /home/dstr/ldevpcib.o
  CC [M]  /home/dstr/e2010.o
  CC [M]  /home/dstr/e140.o
  CC [M]  /home/dstr/e440.o
  CC [M]  /home/dstr/e154.o
  CC [M]  /home/dstr/ldevusbu.o
  LD [M]  /home/dstr/ldevpci.o
  LD [M]  /home/dstr/ldevusb.o
  LD [M]  /home/dstr/ldevpcibm.o
  Building modules, stage 2.
  MODPOST 4 modules
  CC      /home/dstr/ldevice.mod.o
  LD [M]  /home/dstr/ldevice.ko
  CC      /home/dstr/ldevpci.mod.o
  LD [M]  /home/dstr/ldevpci.ko
  CC      /home/dstr/ldevpcibm.mod.o
  LD [M]  /home/dstr/ldevpcibm.ko
  CC      /home/dstr/ldevusb.mod.o
  LD [M]  /home/dstr/ldevusb.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.29.1-102.fc11.i686.PAE/'
вот лог ./start
ernel failure message 1:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<c0569463>] vsnprintf+0x387/0x3b3
*pdpt = 0000000030c78001 *pde = 0000000000000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/rfkill/rfkill2/state
Modules linked in: ldevice(+) vfat fat usb_storage fuse rfcomm sco bridge stp llc bnep l2cap sunrpc ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput nvidia(P) arc4 snd_hda_codec_realtek ecb snd_hda_intel iwl3945 snd_hda_codec snd_hwdep snd_pcm sdhci_pci sdhci mac80211 snd_timer snd btusb mmc_core ricoh_mmc acer_wmi video wmi bluetooth uvcvideo iTCO_wdt lib80211 iTCO_vendor_support videodev firewire_ohci cfg80211 soundcore firewire_core joydev i2c_i801 pcspkr v4l1_compat output snd_page_alloc tg3 serio_raw crc_itu_t nouveau drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]

Pid: 3270, comm: insmod Tainted: P           (2.6.29.1-102.fc11.i686.PAE #1) Aspire 5920G   
EIP: 0060:[<c0569463>] EFLAGS: 00210292 CPU: 1
EIP is at vsnprintf+0x387/0x3b3
EAX: f0d3926c EBX: f0d39200 ECX: 00000000 EDX: 00000014
ESI: 00000000 EDI: f0d2bf3c EBP: f0d2beec ESP: f0d2bec8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process insmod (pid: 3270, ti=f0d2a000 task=f0c80000 task.ti=f0d2a000)
Stack:
00000014 f0d3926c f0d2bef0 f0d39280 c05ef8ac 00000200 f0d39200 f0d3e640
0f700000 f0d2bf0c c05ef8ef f0d2bf3c 00200246 00000000 00000000 f0d3e640
00d21ff4 f0d2bf20 c05ef93f f8a76402 00000000 f0d2bf3c f0d2bf44 f8a76395
Call Trace:
[<c05ef8ac>] ? device_create_vargs+0x2f/0xa2
[<c05ef8ef>] ? device_create_vargs+0x72/0xa2
[<c05ef93f>] ? device_create+0x20/0x22
[<f8a76395>] ? ldev_init+0x9c/0xb3 [ldevice]
[<c040304f>] ? do_one_initcall+0x4f/0x127
[<f8a762f9>] ? ldev_init+0x0/0xb3 [ldevice]
[<c071be81>] ? notifier_call_chain+0x26/0x48
[<c044c1bb>] ? __blocking_notifier_call_chain+0x45/0x51
[<c045926d>] ? sys_init_module+0x8b/0x18a
[<c04094df>] ? sysenter_do_call+0x12/0x34
Code: 0f bf c9 eb 09 8b 0b 31 db f6 c2 02 74 05 89 cb c1 fb 1f 52 8b 55 e8 ff 75 e4 ff 75 ec ff 75 f0 53 51 e8 c3 f2 ff ff 83 c4 18 46 <8a> 0e 84 c9 0f 85 d6 fc ff ff 83 7d dc 00 74 11 3b 45 e8 73 05
EIP: [<c0569463>] vsnprintf+0x387/0x3b3 SS:ESP 0068:f0d2bec8
---[ end trace c9a08f569c5bb508 ]---

Kernel failure message 2:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<c0569463>] vsnprintf+0x387/0x3b3
*pdpt = 000000002fc07001 *pde = 0000000000000000
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/charge_full
Modules linked in: ldevice(+) fuse rfcomm sco bridge stp llc bnep l2cap sunrpc ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec arc4 snd_hwdep ecb iwl3945 snd_pcm nvidia(P) uvcvideo sdhci_pci sdhci snd_timer acer_wmi iTCO_wdt snd video wmi mmc_core ricoh_mmc iTCO_vendor_support btusb mac80211 bluetooth videodev soundcore joydev pcspkr tg3 firewire_ohci lib80211 serio_raw firewire_core i2c_i801 snd_page_alloc v4l1_compat cfg80211 output crc_itu_t nouveau drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
May 26 02:49:39 1 kernel: Pid: 24230, comm: insmod Tainted: P           (2.6.29.1-102.fc11.i686.PAE #1) Aspire 5920G   
EIP: 0060:[<c0569463>] EFLAGS: 00210292 CPU: 1
EIP is at vsnprintf+0x387/0x3b3
EAX: f217246c EBX: f2172400 ECX: 00000000 EDX: 00000014
ESI: 00000000 EDI: f0969f3c EBP: f0969eec ESP: f0969ec8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process insmod (pid: 24230, ti=f0968000 task=f0cf4c20 task.ti=f0968000)
Stack:
00000014 f217246c f0969ef0 f2172480 c05ef8ac 00000200 f2172400 f087f800
0f700000 f0969f0c c05ef8ef f0969f3c 00200246 00000000 00000000 f087f800
00d21ff4 f0969f20 c05ef93f f8a6e402 00000000 f0969f3c f0969f44 f8a6e395
Call Trace:
[<c05ef8ac>] ? device_create_vargs+0x2f/0xa2
[<c05ef8ef>] ? device_create_vargs+0x72/0xa2
[<c05ef93f>] ? device_create+0x20/0x22
[<f8a6e395>] ? ldev_init+0x9c/0xb3 [ldevice]
[<c040304f>] ? do_one_initcall+0x4f/0x127
[<f8a6e2f9>] ? ldev_init+0x0/0xb3 [ldevice]
[<c071be81>] ? notifier_call_chain+0x26/0x48
[<c044c1bb>] ? __blocking_notifier_call_chain+0x45/0x51
[<c045926d>] ? sys_init_module+0x8b/0x18a
[<c04094df>] ? sysenter_do_call+0x12/0x34
Code: 0f bf c9 eb 09 8b 0b 31 db f6 c2 02 74 05 89 cb c1 fb 1f 52 8b 55 e8 ff 75 e4 ff 75 ec ff 75 f0 53 51 e8 c3 f2 ff ff 83 c4 18 46 <8a> 0e 84 c9 0f 85 d6 fc ff ff 83 7d dc 00 74 11 3b 45 e8 73 05
EIP: [<c0569463>] vsnprintf+0x387/0x3b3 SS:ESP 0068:f0969ec8
---[ end trace d251af8929a8e1f3 ]---

А с какой платой пытались работать? А на старой версии Linux все работало?

плата Е14-440 на старой версии федора 9 с ядром 2.6.25 все работало
это компилируется под gcc 4.4.0 и мне кажется что warning при компиляции неспроста да и в логе загрузки видно что ругается на device_create
и warning
/home/dstr/ldevice.c:158: предупреждение: при передаче аргумента 5 ‘device_create’ целое преобразуется в указатель без приведения типа
include/linux/device.h:518: замечание: expected ‘const char *’ but argument is of type ‘int’
говорит что наверное здесь ошибка

Вот нашел

The kernel API for device_create() in 2.6.26 and previous versions was:

extern struct device *device_create(struct class *cls, struct device *parent,
                                   dev_t devt, const char *fmt, ...)

and starting in 2.6.27 it changed to:

struct device *device_create(struct class *cls, struct device *parent,
                             dev_t devt, void *drvdata,
                             const char *fmt, ...)

Note the insertion of a fifth argument. In this case it is a void * at the fourth position in a function that takes a ... argument list.

This is more dangerous that the usual unstable evolutions in kernel APIs in that legacy code may continue to compile without warning on newer kernels, but it will of course crash as the first argument that was intended for the formatting string is now treated as the formatting string itself.

Some code is going to live out of the tree and trip over this. And some code is always going to live out of the tree - if for no other reason than the folks who control the commits have to (and should!) make judgments on what is appropriate, but of course other folks will disagree and carry on with their work. TCP Offload Engines are a good example of that kind of diversity.

Given that, I wonder what the reason for reusing the device_create() name was in between two incompatible versions of that function. There actually was an interim version of the new function called device_create_drvdata() that was used to migrate all of the in-tree uses over to the new style. At the end all the drvdata() versions were renamed back to device_create() where a safer path would seem to have been to simply remove device_create() all together to avoid confusion.

oh well, its not a big deal - but maybe this post will serve as google bait to help someone else resolve the issue more quickly than I could.

понятно... посмотрим что там поменялось...

вообщем я пока заменил на вызов
device_create(lcard_class, NULL, MKDEV(major, i), NULL ,"ldevice%d", i); вроде все работает

ну типа того. Я помотрел, я это поле все равно не использую...