Arjan van de Ven wrote:
Being relatively inexperienced at kernel programming, does this point to
anything that might be obvious to any of you, yet not to me? :) Or are
there any common stumbling blocks in terms of unloading modules on 64bit
linux.
you
1) didn't give the oops here
Sorry, it looks to be failing within chrdev_open. Could this be caused
by not correctly unloading the driver? Here's the oops:
Nov 1 11:39:06 localhost -- MARK --
Nov 1 11:59:06 localhost -- MARK --
Nov 1 12:09:01 localhost kernel: <1>Unable to handle kernel paging
request at ffffffffa0261b80 RIP:
Nov 1 12:09:01 localhost kernel: PML4 103027 PGD 105027 PMD 3e765067 PTE 0
Nov 1 12:09:01 localhost kernel: CPU 0
Nov 1 12:09:01 localhost kernel: Modules linked in: ipv6 hw_random
shpchp pciehp pci_hotplug c4 b1 kernelcapi psmouse ext3 jbd raid5 xor
raid1 raid0 md e1000 ds yenta_socket pcmcia_core sd_mod ide_cd cdrom
ide_disk ide_generic pdc202xx_new aec62xx alim15x3 amd74xx atiixp cmd64x
cs5520 cs5530 cy82c693 generic hpt34x ns87415 opti621 pdc202xx_old
rz1000 sc1200 serverworks siimage sis5513 slc90e66 triflex trm290
via82cxxx floppy usb_storage piix ide_core fbcon vga16fb vgastate
usbserial usbkbd ehci_hcd uhci_hcd thermal processor fan ata_piix libata
scsi_mod unix font vesafb cfbcopyarea cfbimgblt cfbfillrect
Nov 1 12:09:01 localhost kernel: Pid: 5612, comm: hardserver Not
tainted 2.6.8-11-amd64-generic
Nov 1 12:09:01 localhost kernel: RIP: 0010:[cdev_get+14/73]
<ffffffff80163453>{cdev_get+14}
Nov 1 12:09:01 localhost kernel: RSP: 0018:000001003628de48 EFLAGS:
00010246
Nov 1 12:09:01 localhost kernel: RAX: 0000000000000000 RBX:
ffffffffa0261b80 RCX: 0000000000000000
Nov 1 12:09:01 localhost kernel: RDX: 000001003b5b9080 RSI:
000001003b5b9080 RDI: 0000010002177680
Nov 1 12:09:01 localhost kernel: RBP: 000001003c45bd38 R08:
000001003ea831a8 R09: 000001003ea831a8
Nov 1 12:09:01 localhost kernel: R10: 000001003b5b9080 R11:
00000000000000f0 R12: 0000000000000000
Nov 1 12:09:01 localhost kernel: R13: 0000000000000000 R14:
000001003b5b9080 R15: 0000000000000000
Nov 1 12:09:01 localhost kernel: FS: 0000002a959c2090(0000)
GS:ffffffff80391580(0000) knlGS:0000000000000000
Nov 1 12:09:01 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
Nov 1 12:09:01 localhost kernel: CR2: ffffffffa0261b80 CR3:
0000000000101000 CR4: 00000000000006e0
Nov 1 12:09:01 localhost kernel: Process hardserver (pid: 5612,
threadinfo 000001003628c000, task 0000010038bdc230)
Nov 1 12:09:01 localhost kernel: Stack: 0000000000000000
0000010002177680 000001003c45bd38 ffffffff80163573
Nov 1 12:09:01 localhost kernel: 000001003ea831a8
000001003ea831a8 000001003b5b9080 000001003c45bd38
Nov 1 12:09:01 localhost kernel: 000001003fbbeec0 0000000000000000
Nov 1 12:09:01 localhost kernel: Call
Trace:<ffffffff80163573>{chrdev_open+180}
<ffffffff8015bd2c>{dentry_open+205}
Nov 1 12:09:01 localhost kernel:
<ffffffff8015be53>{filp_open+62} <ffffffff8023252e>{tcp_listen_start+325}
Nov 1 12:09:01 localhost kernel: <ffffffff80166c0a>{getname+130}
<ffffffff8015c04e>{sys_open+57}
Nov 1 12:09:01 localhost kernel:
<ffffffff8010fc92>{system_call+126}
Nov 1 12:09:01 localhost kernel:
Nov 1 12:09:01 localhost kernel: Code: 83 3b 02 74 32 ff 83 00 01 00 00
e8 41 38 04 00 48 85 c0 48
Nov 1 12:09:06 localhost kernel: <6>ACPI: PCI interrupt
0000:02:03.0[A] -> GSI 24 (level, low) -> IRQ 24
Nov 1 12:09:06 localhost kernel: ACPI: PCI interrupt 0000:07:06.0[A] ->
GSI 18 (level, low) -> IRQ 18
Nov 1 12:19:06 localhost -- MARK --
Nov 1 12:39:06 localhost -- MARK --
2) didn't post a URL to the driver source
Sorry again. Here is the source. Right at the bottom, it appears to be
calling pci_unregister_driver and unregister_chrdev as it should.
http://www.f0rmula.com/stuff/hostif.c
/var/log/messages says:
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy: entered
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy:
freeing irq, 18
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy:
freeing IO BAR, 1
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy:
freeing MEM BAR, 2
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy:
freeing pdev
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_pci_remove: entered
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: i21285_destroy: entered
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_outl: addr ec34, data c
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy: entered
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy:
freeing irq, 12
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy:
freeing IO BAR, 1
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy:
freeing MEM BAR, 2
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: nfp_dev_destroy:
freeing pdev
Nov 2 13:11:54 localhost kernel: nfdrv 2.9.25+: cleanup_module: Module
unloaded
I thought that should prevent the driver from being able to kernel
oops. Is there anything else that I should be calling? Or could it be
the parameters I'm calling these functions with? (bearing in mind this
works fine on a similar 32bit kernel).
so.. how is anyone supposed to help?
I was thinking that there may have been a common issue that would allow
a driver oops the kernel if not unloaded properly. Obviously not.
Thanks for any advice, it's much appreciated.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]