Re: Trouble unloading a module..

[James Hansen]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/