Bugzilla – Bug 157460
reading /proc/ioports oopses after cd1 finished
Last modified: 2006-10-13 13:36:57 UTC
Got the following oops after CD1 finished and yast hung then. r_show is from /proc/ioports (there is another in reiserfs but it is not compiled in). This probably means some driver didn't free their resources properly. The address is in the modules area, so someone who got unloaded still has a dangling pointer to a string. No dmesg entry that would suggest that any modules got unloaded. I had removed thermal and processor manually before because I suspected them. Will try without that again. But I looked through their source and they don't free any ioports. Unable to handle kernel paging request at ffffffff881dc328 RIP: <ffffffff801ca6d0>{strnlen+17} PGD 103027 PUD 105027 PMD 3d7f9067 PTE 0 Oops: 0000 [1] last sysfs file: /block/hda/size CPU 0 Modules linked in: ext3 jbd multipath raid6 raid5 xor raid1 raid0 parport_pc parport dm_snapshot dm_mod nls_utf8 fa n pcmcia firmware_class yenta_socket rsrc_nonstatic pcmcia_core sbp2 ohci1394 ieee1394 usb_storage ohci_hcd usbhid ehci_hcd usbcore atiixp button battery loop ide_disk nfs nfs_acl lockd sunrpc cramfs vfat fat nls_iso8859_1 nls_cp4 37 af_packet edd sg st sd_mod sr_mod scsi_mod ide_cd cdrom ide_core Pid: 2884, comm: y2base Tainted: G U 2.6.16-rc5-git9-2-default #1 RIP: 0010:[<ffffffff801ca6d0>] <ffffffff801ca6d0>{strnlen+17} RSP: 0018:ffff81002d0edd50 EFLAGS: 00010297 RAX: ffffffff881dc328 RBX: ffff81002d0edda8 RCX: ffffffff802cd334 RDX: ffff81002d0ede98 RSI: fffffffffffffffe RDI: ffffffff881dc328 RBP: ffff81000955438a R08: 00000000ffffffff R09: ffff81002d0edcb8 R10: 0000000000000004 R11: 0000000000000000 R12: ffffffff881dc328 R13: 00000000ffffffff R14: 0000000000000000 R15: ffff810009554fff FS: 00002b0091c7ca50(0000) GS:ffffffff803f7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffff881dc328 CR3: 000000003191b000 CR4: 00000000000006e0 Process y2base (pid: 2884, threadinfo ffff81002d0ec000, task ffff8100323dc850) Stack: ffffffff801cb6b4 0000000000000c84 ffff81000955437c ffffffff802cd334 ffff810008e2fac0 ffff81003a5548c0 000000000000037c 0000000000000400 0000000000000000 00002aaaacf0d000 Call Trace: <ffffffff801cb6b4>{vsnprintf+825} <ffffffff8017d5ca>{seq_printf+103} <ffffffff8012b040>{ioports_open+0} <ffffffff8017d87c>{seq_open+77} <ffffffff80154b61>{vma_merge+144} <ffffffff8012b0d4>{r_show+104} <ffffffff8017db01>{seq_read+468} <ffffffff80162f58>{vfs_read+203} <ffffffff801632ad>{sys_read+69} <ffffffff8010a3a6>{system_call+126} Code: 80 38 00 75 ef 48 29 f8 c3 31 c0 eb 12 41 38 c8 74 0a 48 ff RIP <ffffffff801ca6d0>{strnlen+17} RSP <ffff81002d0edd50> CR2: ffffffff881dc328
Hmm, it didn't oops when I didn't unload processor/thermal so it might be actually that.
Pavel, please look into this. Thanks!
Does it also happen on running system? Can you find out if it is processor or thermal?
How common is it (for a user or an app) to read /proc/ioports in this situation? If we assume this will happen very rarely then severity normal is ok, otherwise I would raise it to major. And Andi, can you answer comment #3?
Reading ioports is common (various hw tools do it). Unloading these modules might be not common. What we can do as a quick fix is to just make the module un-unloadable.
Okay, does this still happen in released version? Do we want to do anything with it?
Too long in needinfo.