| Summary: | visor* modules fill the logs with undefined symbols | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Chris Denice <eatdirt> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | MGA5TOO | ||
| Source RPM: | kernel-3.18.0-1.mga5.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Chris Denice
2014-12-09 19:58:16 CET
Still there with kernel-3.19.0-desktop
Samuel Verschelde
2015-05-31 23:50:28 CEST
Assignee:
bugsquad =>
tmb You have not blocked visorutil wich is the first module spamming... and it probably contains code that loads s the visorchannel module, something the modprobe blacklist wont prevent Thanks, funnily enough, I only sorted this out very recently :) The visor chain of modules is triggered by visorbus and visorhba, which goes into initrd. So even a blacklist a posteriori does not work, one has to regenerate the initrd with a proper blacklist lists, or wait for the next kernel to debug the blacklist :) Here a working blacklist for visor: cat modprobe.d/visor.conf blacklist visorbus blacklist visorhba blacklist visorchipset blacklist visoruislib blacklist visor blacklist visorutil blacklist visorchannel Don't know if we need to include it though. Mass-reassigning all bugs with "kernel" in the Source RPM field that are assigned to tmb, to the kernel packagers group, because tmb is currently MIA. Assignee:
tmb =>
kernel |