Mageia Bugzilla – Bug 6914
update request: kernel-3.3.8-2.mga2
Last modified: 2012-08-23 15:18:37 CEST
There is now a kernel-3.3.8-2.mga2 to validate.
This updates the kernel to latest 3.3 series.
It also fixes the following CVEs:
set correct msg_namelen (CVE-2012-3430)
verify origin of netlink connector message (CVE-2012-2669)
Use 'ret' instead of abusing 'i' in udf_load_logicalvol()
Avoid run away loop when partition table length is corrupted (CVE-2012-3400)
Fortify loading of sparing table (CVE-2012-3400)
clear the tfile_check_list on -ELOO (CVE-2012-3375)
fix 32bit PAE pmd walk vs pmd_populate SMP race condition (CVE-2012-2372)
fix resv_map leak in error path (CVE-2012-2390)
Other fixes in this update:
fix crash with mirror recovery and discard
avoid crash when stopping md array races with closing other open fds
close some possible races on write errors during resync
fix use-after-free bug in RAID1 data-check code
Don't try to recovery unmatched (and unused) chunks
fix failure when trying to repair a read error
In ops_run_io, inc nr_pending before calling md_wait_for_blocked_rde
Do not add data_offset before call to is_badbloc
delayed stripe bits fix
aesni-intel - fix unaligned cbc decrypt for x86-32
add another Ironlake host bridge
edid: don't return stack garbage from supports_rb
ttm: Fix buffer object metadata accounting regression v2
ttm: Fix spinlock imbalance
don't register the ACPI video bus
Adding TV Out Missing modes
always use RPNSWREQ for turbo change requests
Mark the ringbuffers as being in the GTT domain
enable vdd when switching off the eDP panel
Fix eDP blank screen after S3 resume on HP desktops
Flush any outstanding work to turn the VDD off
properly handle interlaced bit for sdvo dtd conversion
Refactor the deferred PM_IIR handling into a single function
rip out the PM_IIR WARN
wait for a vblank to pass after tv detect
disp: fix dithering not being enabled on some eDP macbooks
fbcon: using nv_two_heads is not a good idea
add some additional 6xx/7xx/EG register init
audio: don't hardcode CRTC id
fix bank information in tiling config
fix HD6790, HD6570 backend programming
fix regression in UMS CS ioctl
fix tiling and command stream checking on evergreen v3 (mga #6715)
fix typo in trinity tiling setup
fix vm deadlocks on cayman
fix VM page table setup on SI
fix XFX quirk
properly program gart on rv740, juniper, cypress, barts, hemlock
Fix nasty write past alloced memory area
run delayed directory updates during log replay (fixes crash)
fix duplicated mnt_drop_write call in EXT4_IOC_MOVE_EXT
fix the free blocks calculation for ext3 file systems w/ uninit_bg
Gracefully refuse miscdev file ops on inherited/passed files
Fix lockdep warning in miscdev operations
Properly check for O_RDONLY flag before doing privileged open
fs/locks.c: Remove easily user-triggerable BUG from generic_setlease
HID: add support for 2012 MacBook Pro Retina
Input: bcm5974 - Add support for 2012 MacBook Pro Retina
Support embedded LED on Synaptics devices (#5694)
gspca-core: Fix buffers staying in queued state after a stream_off
add ext PA workaround for BCM4331 and BCM43431
Disable ASPM L1 on 82574
Remove special case for 82573/82574 ASPM L1 disablement
Apply short DMA frag workaround to 5906 (mga #6293)
intel_ips: blacklist HP ProBook laptops
* scsi & usb-storage:
add try_rc_10_first flag
Silence unnecessary warnings about ioctl to partition (requested by coling)
Increase the timeout for controller save/restore state operation
fix potential deadlock in regulatory
always monitor for stuck queues
don't mess up the SCD when removing a key
disable the buggy chain extension feature in HW
do not use shadow registers by default
don't mess up the SCD when removing a key
unregister LEDs if mac80211 registration fails
update BT traffic load states correctly
use correct supported firmware for 6035 and 6000g2
Add new USB IDs
add more devices ids
New USB IDs
fix oops on early interrupt
enable EFI_STUB support (#6598)
Is this likely to fix bug 6077 Thomas?
If not then I won't mess around with that computer.
(In reply to comment #1)
> Is this likely to fix bug 6077 Thomas?
> If not then I won't mess around with that computer.
Not directly, unless it gets fixed as a "side-effect" of all other fixes...
But I left comments on 6077 on stuff to test...
shlomif@lap:~$ uname -r
From updates_testing on Mageia 2, everything appears to be in working order: KDE, LXDE, VLC playing video+sound, claws-mail, wifi, Samba, the works.
My x86-64 Acer laptop's spec is:
I also have an Acer Aspire 5738DZG laptop with the following specs:
Intel Pentium(R) Dual-Core CPU T4300 @ 2.10GHz. (x86-64).
ATI Mobility Radeon™ HD 4570 (r700)
15.6״ 3D HD LCD Screen.
3 GB Memory
320 GB Hard Disk Drive.
“DVD Super Multi DL drive”
Acer Nplify™ 802.11b/g/n.
-- Shlomi Fish
tmb please take a look here:
All kernel flavours boot ok in virtualbox, Mageia 2 i586
Testing on MGA2, i586.
I will report back tomorrow.
Testing complete for the kernel-desktop-3.3.8-2.mga2-1-1.mga2 on Mageia release 2 (Official) for x86_64 ,for me it's Ok ,nothing to report.
Laptop Asus K73S ,Intel Core i3-2350M, 2.3GHz
Kernel 3.3.8-desktop-2.mga2 on a 4-processor x86_64
Tested kernel-desktop-3.3.8-2.mga2 on i586 (Dell Latitude D820 laptop - only standard drivers)
Infrastructure OK: install (kernel-desktop, kernel-desktop-latest, kernel-doc, kernel-userspace-headers, perf), boot, sound, wifi, usb.
Comment: trying to load perf from rpmdrake I got: "Rpmdrake or one of its priority dependencies needs to be updated first. Rpmdrake will then restart" (I did not go farther, installed perf from commandline urpmi).
Did about an hours production work (fully customized KDE environment) on the thus installed system: nothing abnormal observed.
Some items of the Dell Latitude specifications
Core Duo T2400 CPU @ 1.83 GHz
NVIDIA Quadro NVS 120 graphics solution with 512MB TurboCache
(Intel 945GM/GMS, 943/940GML controller)
Dell Wireless 1390 WLAN (802.11b/g 54Mbps) (Intel 3945ABG)
Bluetooth radio (Toshiba stack)
Testing complete on MGA2, i586.
What was tested: only kernel-desktop; boot, sound, wifi, bluetooth, usb, card reader all ok, used for several hours without problems
What was not tested: suspend, fingerprint reader
System: Laptop Thinkpad L510
Intel Core 2 Duo T6570 / 2.10 GHz
Intel GMA 4500MHD Dynamic Video Memory Technology 5.0
RTL 8191SEvB Wireless LAN Controller
HDA Intel (ALC 269 Analog) Sound card
Summary: Everything OK, nothing to report.
My virtual box kernel modules did not get installed.
systemctl status virtualbox.service
virtualbox.service - LSB: VirtualBox Linux kernel module
Loaded: loaded (/etc/rc.d/init.d/virtualbox)
Active: active (exited) since Fri, 10 Aug 2012 05:03:08 -0400
Process: 1132 ExecStart=/etc/rc.d/init.d/virtualbox start (code=exited, status=0/SUCCESS)
# rpm -q --scripts virtualbox-kernel-3.3.8-desktop-2.mga2
postinstall scriptlet (using /bin/sh):
/usr/sbin/dkms install --binary -m virtualbox -v 4.1.18-1.mga2 -k 3.3.8-desktop-2.mga2 --rpm_safe_upgrade
/usr/sbin/dkms status -m virtualbox -v 4.1.18-1.mga2
# /usr/sbin/dkms install --binary -m virtualbox -v 4.1.18-1.mga2 -k 3.3.8-desktop-2.mga2 --rpm_safe_upgrade
dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
Error! Bad conf file.
Your dkms.conf is not valid.
"lsmod|grep vb" has no output.
No problem so far on my work Mageia 2 64 bits system, with nvidia drivers.
tmb, any comment to comment #10?
(In reply to comment #10)
> My virtual box kernel modules did not get installed.
> systemctl status virtualbox.service
> virtualbox.service - LSB: VirtualBox Linux kernel module
> Loaded: loaded (/etc/rc.d/init.d/virtualbox)
> Active: active (exited) since Fri, 10 Aug 2012 05:03:08 -0400
> Process: 1132 ExecStart=/etc/rc.d/init.d/virtualbox start
> (code=exited, status=0/SUCCESS)
> CGroup: name=systemd:/system/virtualbox.service
> # rpm -q --scripts virtualbox-kernel-3.3.8-desktop-2.mga2
> postinstall scriptlet (using /bin/sh):
> /usr/sbin/dkms install --binary -m virtualbox -v 4.1.18-1.mga2 -k
> 3.3.8-desktop-2.mga2 --rpm_safe_upgrade
> /usr/sbin/dkms status -m virtualbox -v 4.1.18-1.mga2
> # /usr/sbin/dkms install --binary -m virtualbox -v 4.1.18-1.mga2 -k
> 3.3.8-desktop-2.mga2 --rpm_safe_upgrade
> dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
> dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
> dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
> Error! Bad conf file.
> Your dkms.conf is not valid.
> "lsmod|grep vb" has no output.
Hm, how did you get into this? did you uninstall any of the 3.3.8 series kernels before this happend ?
Testing complete on MAG2, x86_64, everything seems ok (sound, driver fgrlx, boot, suspend)
I've seen no problems, and would validate the update, but I think
bug 7025 opened for comment 10, needs to be fixed first, otherwise
people will not be able to run VirtualBox guests.
I have done simple tests now also on a 64-bit partition on my desktop (kernel-server-3.3.8-2, standard drivers only). I have not been able to do extensive testing in everyday production, but the system installs well, and rapid checking of the interface to the periphery are all satisfactory
(In reply to comment #13)
> (In reply to comment #10)
> > My virtual box kernel modules did not get installed.
> > # /usr/sbin/dkms install --binary -m virtualbox -v 4.1.18-1.mga2 -k
> > 3.3.8-desktop-2.mga2 --rpm_safe_upgrade
> > dkms.conf: Error! No 'DEST_MODULE_LOCATION' directive specified.
> > dkms.conf: Error! No 'PACKAGE_NAME' directive specified.
> > dkms.conf: Error! No 'PACKAGE_VERSION' directive specified.
> > Error! Bad conf file.
> > Your dkms.conf is not valid.
> > "lsmod|grep vb" has no output.
> Hm, how did you get into this? did you uninstall any of the 3.3.8 series
> kernels before this happend ?
No uninstalls involved. After seeing the attachment posted to
I'm wondering if there is a problem with dkms itself, such that the
files are getting deleted from the source dir, prior to getting
Seems strange version numbering Thomas, is the extra 'mga2' intended?
I've taken bug 7025 off of the depends on list, as I cannot recreate the
problem, even by starting with a clean install, and then installing the
relevant packages in the same order as shown by my syslog.
I think we can validate this once Thomas has responded to the query in comment 18.
For comment 18, its intended.
Thats how we fool rpm/urpmi to never upgrade (rpm -U) a kernel, thus removing the previous one, and potentially break users systems if the new kernel would not work... instead we force an install (rpm -i)
Basically we stick the real version and release as part of name (the first part "3.3.8-2.mga2") to show exactly what kernel it is, and the second part "1-1.mga2" is the version rpm reads/compares, always version 1, release 1 (meaning rpm/urpmi never sees an updated one).
And to finally top it of we have the kernel-*-latest that uses the real version "3.3.8" and release "2.mga2" that pulls the specially named kernels so people gets automatic updates :)
One thig that still is missing before I can push this kernel is the fglrx update for mga2 (bug 7086) still needs i586 validation as I will push prebuilt modules as part of / at the same time as the kernel update..
> Basically we stick the real version and release as part of name (the first part
> "3.3.8-2.mga2") to show exactly what kernel it is, and the second part
> "1-1.mga2" is the version rpm reads/compares, always version 1, release 1
> (meaning rpm/urpmi never sees an updated one).
I understand (in both senses of the word) - clever (the french would say "futé"). I looked back: this trick has already been used in Mageia 1. Once you realise, quite evident - but not evident for the naive user who tries to understand the listing provided when he does an update
In the long run: can a solution be conceived that is more transparent - easier to understand by the non-specialist? OK, something in the package should tell urpmi that packages with preceding versions must not be removed: the trick hides this instruction in the syntax of the splitting off of the version part of the package name.
Would it make sense to make urpmi understand that packages with a given pattern in their name (in the kernel example: starting by kernel and not kernel-*-latest) should avoid removing their predecessor? Is kernel the only envisageable case where this problem might occur (with other words: do I suggest finding a general solution for a very isolated problem)? - An approach might, for instance, be: have a file in /etc/urpmi/... that contains regular expressions which contain such patterns?
Sorry, this is slightly off-topic for a bugzilla report.
Thanks for the explanation Thomas:)
nvidia I think you mean for bug bug 7086 btw
You can maybe discuss that further on the ML Juergen
Validating this one then.
Comment 0 for advisory and srpms
Could sysadmin please push from core/updates_testing to core/updates when bug 7086 has been validated.
(In reply to comment #22)
> > Basically we stick the real version and release as part of name (the first part
> > "3.3.8-2.mga2") to show exactly what kernel it is, and the second part
> > "1-1.mga2" is the version rpm reads/compares, always version 1, release 1
> > (meaning rpm/urpmi never sees an updated one).
> I understand (in both senses of the word) - clever (the french would say
> "futé"). I looked back: this trick has already been used in Mageia 1. Once you
Oh, it's actaully way older :)
I introduced it in Mandriva main kernel on:
Fri Aug 24 2007 with 126.96.36.199-1mdv2008.0
and before that in kernel-tmb series as of:
Mon May 1 2006 with 188.8.131.52-4mdk
> Would it make sense to make urpmi understand that packages with a given pattern
> in their name (in the kernel example: starting by kernel and not
> kernel-*-latest) should avoid removing their predecessor? Is kernel the only
> envisageable case where this problem might occur (with other words: do I
> suggest finding a general solution for a very isolated problem)? - An approach
> might, for instance, be: have a file in /etc/urpmi/... that contains regular
> expressions which contain such patterns?
It already does support it with /etc/urpmi/inst.list,
but it was decided that it was not safe enough...
If a beginner tries to install a rpm manually, reading on the net that rpm -U is the way to install a new package, it would break the install, and that we want to avoid as much as possible, as a non-booting system tends to be harder to fix due to a broken kernel, than fixing other stuff. So we opted for better safe than sorry...
but this is indeed OT for this BR :)
(In reply to comment #23)
> Thanks for the explanation Thomas:)
> nvidia I think you mean for bug bug 7086 btw
yep, nvidia not fglrx, thanks for correcting :)