Bug 709419

Summary: After 0.35.1-5 update kernel modules won't unload
Product: [Fedora] Fedora Reporter: Jeroen Beerstra <jeroen>
Component: libcgroupAssignee: Josh Boyer <jwboyer>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 13CC: bsingharora, dhaval.bugzilla, jsafrane, varekova
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-27 11:42:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
cgroup config
none
cgrulesd config none

Description Jeroen Beerstra 2011-05-31 17:09:12 UTC
Created attachment 502047 [details]
cgroup config

Description of problem:

After the last libcgroup update kernel modules no longer unload, basicly this makes it impossible to cleanly reboot/halt my workstation.

Version-Release number of selected component (if applicable):

libcgroup-0.35.1-5.fc13.x86_64
kernel-2.6.34.8-68.fc13.x86_64

How reproducible:

reboot with cgconfig and cgred on, the first service that unoad one or more modules will hang forever.


Steps to Reproduce:
1. Boot with kernel flag "single" 
2. unload a module
3. exec "service cgconfig start"
4. unload another module
  
Actual results:

rmmod hangs indefinitely 

Expected results:

rmmod should exec correctly

Additional info:

I use cgconfig/cgrulesd as an alternative to the infamous 200 lines patch, config files are attached.

Comment 1 Jeroen Beerstra 2011-05-31 17:10:34 UTC
Created attachment 502048 [details]
cgrulesd config

Comment 2 Dhaval Giani 2011-05-31 17:15:13 UTC
cat $CPU_CGROUP_PATH/admingroup/cpu.rt*

please

replace $CPU_CGROUP_PATH with whatever path you have the cpu subsystem mounted. It should most probably be at /sys/kernel/fs/cgroup/cpu

Comment 3 Jeroen Beerstra 2011-05-31 17:23:18 UTC
cat /cgroup/cpu/admingroup/cpu.rt*
1000000
0

Comment 4 Dhaval Giani 2011-05-31 17:29:11 UTC
ok, we are almost there,

cat /etc/cgconfig.conf

The reason is that rmmod needs rt privileges, and you have put it in a group without and rt runtime. So, you need to setup cgconfig to create the admingroup with some rt time. (i think 10000 should be sufficient)

Dhaval

Comment 5 Dhaval Giani 2011-05-31 17:29:53 UTC
I am closing it, since its not a bug, but I can give you further instructions here itself, if you need them.

Comment 6 Dhaval Giani 2011-05-31 17:31:22 UTC
Ok, my mistake, I did not notice that that file was also available.

update

group admingroup {
	perm {
		task {
			uid = root;
                        gid = root;
		}
                admin {
			uid = root;
			gid = root;
		}
	}
	cpu {
		cpu.shares = 384;
                cpu.rt_runtime_us = 10000;
	}
}

should do it for you.

Comment 7 Jeroen Beerstra 2011-05-31 18:00:00 UTC
TY

# cat /cgroup/cpu/cpu.rt*
1000000
950000
# cat /cgroup/cpu/admingroup/cpu.rt*
1000000
950000

Problem persists, also in single user mode after only "service cgconfig start" (thus without anything assigned to the admingroup). Something else not set altogether?

Comment 8 Jeroen Beerstra 2011-06-01 15:29:34 UTC
I understand I need to fox things if I made a mistake, however:

1 This was not a problem before
2 Problem also occurs when nothing is assigned to a specific (possibly faulty) control group, even after "service cgconfig stop"

Comment 9 Fedora Admin XMLRPC Client 2011-06-22 17:14:03 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 10 Bug Zapper 2011-06-27 11:42:02 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.