Kernel 2.6.31 freeze the PC

[Andrea Florio]

I'm an happy linux tester, i don't believe about distro wars, so here i am to report that bug that looks affect kernel 2.6.31 and not openSUSE (my distro) or ubuntu (your distro).

Both, openSUSE 11.2 and Ubuntu 9.10 have kernel 2.6.31 and both freeze after few minutes. This not happen with any other previous version of any distro.

This freeze make me impossible to collect logs informations since i'm not able to complete installation process (the freeze come before installation complete).

you may collect other infos here:

https://bugzilla.novell.com/show_bug.cgi?id=539541

some hardware infos attached

[Contezero (contezero)]

Tried to attach boot.msg but bugzilla give me timeout error.

[Contezero (contezero)]

Created an attachment (id=229941)
opensuse 11 boot.msg

opensuse 11 boot.msg

[Contezero (contezero)]

Created an attachment (id=229942)
opensuse 10.3 boot.msg

opensuse 10.3 boot.msg

[Trenn-novell (trenn-novell)]

Can you try:
acpi_enforce_resources=strict
boot param, pls.

> it freezes randomly.
What exactly does this mean?
Every 5-10 minutes.
Only on some boots.
...

What kind of machine/model is that?

[Trenn-novell (trenn-novell)]

Not sure, these chould be unrelated...
But bug #393675 also shows an ACPI IO conflict with the same IO region.

Strange that here an smbus driver tries to claim the resource and on the other bug a PNP driver (even claiming a IRQ resource?)?
I didn't know that PNP finally checks for this...
Maybe Jean can shed some light what could be behind this IO region, I do not have much experience here.

[Contezero (contezero)]

> Can you try:
> acpi_enforce_resources=strict
> boot param, pls.

I've tried but it freeze.
With "freeze randomly" I mean that sometimes it freeze after 1 minute and sometimes it freeze after 5 minutes, but it always freezes.
When the system freezes the keyboard stops working (I can move the mouse but I can't interact with the screen, the screen seems a snapshot)
With acpi=off the system starts without mouse (only the keyboard works) but it freeze after some minutes.

[Contezero (contezero)]

Created an attachment (id=230661)
hwinfo opensuse 11

hwinfo opensuse 11

[Contezero (contezero)]

Created an attachment (id=230662)
hwinfo opensuse 10.3

hwinfo opensuse 10.3

[Trenn-novell (trenn-novell)]

Ahh a Sempron..., hmmm, but not a mobile one.
Does nohz=off boot param help?
Then it's a duplicate of bug #396220.

Please also upload acpidump.
If your BIOS is rather old, pls update the BIOS.
If things are still broken, pls also upload acpidump of the updated BIOS.

Do you run sensor tools to read fan/temperature?
If yes, you should disable that first, maybe it's that.

[Contezero (contezero)]

nohz=off or highres=off doesn't help.
I've the latest BIOS from asus.
Actually I'm on vacancy, and I've no access to the PC, when I'll return I'll upload acpidump.

[Richard-nod (richard-nod)]

same problem here on an asus z53m notebook (amd turion 64 mobile mk38).
"apci=off" seems to help *sometimes*.

acpidump and hwinfo are attached.

the notebook worked with 10.3 perfect.

cheers,
//richard

[Richard-nod (richard-nod)]

Created an attachment (id=231461)
acpidump

[Richard-nod (richard-nod)]

Created an attachment (id=231462)
hwinfo

[Trenn-novell (trenn-novell)]

Puhh, this is hard... there is nothing obvious in dmesg.
Is the temperature controlled by ACPI:
cat /proc/acpi/thermal_zone/*/*
or is this dir empty?

If there is something, does this help:
for x in /proc/acpi/thermal_zone/*/polling_frequency; do echo 5 >$x;done

[Richard-nod (richard-nod)]

Created an attachment (id=231555)
ls-lR /proc/acpi/thermal_zone/

[Richard-nod (richard-nod)]

hmm, this does also not help. :-(
/proc/acpi/thermal_zone/TZ200/temperature says "60°C". this is wrong.
sensos says 41°C.

cheers,
//richard

[Trenn-novell (trenn-novell)]

This answers my question from comment #9:
> Do you run sensor tools to read fan/temperature?
> If yes, you should disable that first, maybe it's that.
Have a you also already tried to disable sensors?

Does:
grep -i criticial /var/log/messages
reveal critical temperature shutdowns?

Please also show output of:
for x in /proc/acpi/thermal_zone/*/*; do echo $x;cat $x;echo;done

What kind of machine is this?
Is there a newer BIOS available?

[Richard-nod (richard-nod)]

this is the output:
--cut--
/proc/acpi/thermal_zone/TZ00/cooling_mode
<setting not supported>

/proc/acpi/thermal_zone/TZ00/polling_frequency
polling frequency: 30 seconds

/proc/acpi/thermal_zone/TZ00/state
state: ok

/proc/acpi/thermal_zone/TZ00/temperature
temperature: 60 C

/proc/acpi/thermal_zone/TZ00/trip_points
critical (S5): 127 C
passive: 105 C: tc1=2 tc2=10 tsp=30 devices=P001
--cut--

grep -i critical /var/log/messages outputs nothing.

the notebook is an "asus 53 M series" (kind of crappy notebook... ;))
motherboard version f3m.

more details follow tomorrow...

[Trenn-novell (trenn-novell)]

Looks fine. That your temperature is 60C seem to come from some kind of offset used in ACPI, I doubt that 127 C is the real critical trip point.

If the machine freezes can you still press keys, e.g. switch to console 10 by:
CTRL-ATL-F10 ?
Can you also double check the rest: not running sensors, e.g. uninstalling (also libsensors).
You can also already start to remove ACPI modules.
I've written down a small file how to do that:
ftp.suse.com/pub/people/trenn/How_to_exclude_ACPI_modules_in_OPEN_SUSE_11_0_and_newer.txt

I do not have that mucht time. But as this is rather sever, I try to keep up.

[Richard-nod (richard-nod)]

i did a bios update.
now the maschine is DEAD! :-(

maybe i can fix it in a few days...

[Jdelvare (jdelvare)]

Random comments:

The resource conflict _message_ is new in openSuse 11.0, not the conflict itself. If the conflict wasn't causing trouble in 10.3, I doubt it will in 11.0. According to comment #6, preventing the native SMBus driver to load didn't help Michele, which would confirm that the freeze isn't caused by the conflict.

I've looked at Richard machine's DSDT and it gets its temperature from a device at address 0x4c on the SMBus (presumably an LM90 or ADM1032 or compatible chip), from register 0x01. This means that you should really only use either ACPI or lm-sensors to get the temperature, but not both. Booting with acpi_enforce_resources=strict is one way to achieve this.

This DSDT is pretty confusing, BTW... Many things are declared twice, for example the RBYT and WBYT methods.

Another thing I've noticed is that the DSDT initializes the temperature value to 60 degrees C:

                    Name (LTMP, 0x3C)

Which is the value reported by Richard. The RTMP method is supposed to overwrite it with a temperature value read from the thermal sensor chip, but I suspect that it doesn't happen. That would explain why the values reported by ACPI and sensors are different. I have no idea why RTMP fails to overwrite the value of LTMP though... The code looks OK to me (but then again I am no expert.)

But anyway, at this point we have no reason to believe that the problem is related to thermal management or ACPI, do we? This might as well be a problem with any other part of the kernel, or even outside the kernel. For example the X server could be responsible for the lockup. Does the lockup happen if you boot in runlevel 3 (no X server)?

It would be useful to find out where the freeze is happening, by enabling the magic SysRq mechanism and hitting SysRq+p and SysRq+t when the system is frozen. If we know where it freezes, this would at least give us something to start from.

[Contezero (contezero)]

Created an attachment (id=235229)
acpidump

[Aj-novell (aj-novell)]

Information was provided

[Trenn-novell (trenn-novell)]

Not really:
Michele, can you try what Jean suggested:
It would be useful to find out where the freeze is happening, by enabling the
magic SysRq mechanism and hitting SysRq+p and SysRq+t when the system is
frozen. If we know where it freezes, this would at least give us something to
start from.

[Contezero (contezero)]

OK, I've enabled SysRq (cat /proc/sys/kernel/sysrq gives 1), if I hit SysRq+p and SysRq+t after the freeze nothing happens, the system remain freezed, (I can move the mouse, but nothing else) I can only reboot with SysRq + R E I S U B

[Trenn-novell (trenn-novell)]

> I can only reboot with SysRq + R E I S U B
Does that mean all of these reboot: SysRq + R, SysRq + E,...?

We do not know for sure whether it is ACPI, right?

> and after some minutes the system freeze.
Hmm, could you try to boot with: CPUFREQ=off boot param (hope this is the right one).
Which graphics driver are you using, could it be related to fglrx or radeonhd?
Try the other one, or frambuffer X driver.

[Trenn-novell (trenn-novell)]

> if I hit SysRq+p and SysRq+t after the freeze nothing happens
Try to increase log level first, with e.g.: SysRq+8, then SysRq+t should print a lot?

[Contezero (contezero)]

> Does that mean all of these reboot: SysRq + R, SysRq + E,...?
Yes.

> We do not know for sure whether it is ACPI, right?
I really don't know..
I suspect it could be a temperature problem (wrong temperature reported) because if I use xfce the freeze is less frequent (xfce is more lightweight then kde).

> Which graphics driver are you using, could it be related to fglrx or radeonhd?
> Try the other one, or frambuffer X driver.
I have an integrated graphic card (via? I don't remember) and an AGP ati x300
The ati is the card that I use (with radeon driver), the integated card is disabled.
Before posting the bug I've tried to test with the integrated card, but it hasn't helped, so I don't think that the problem is in the graphic driver.

> Hmm, could you try to boot with: CPUFREQ=off boot param (hope this is the
> right one).
> Try to increase log level first, with e.g.: SysRq+8, then SysRq+t should print
> a lot?

I'll try tomorrow.

[Contezero (contezero)]

Created an attachment (id=253787)
/var/log/messages after SysRq+p and SysRq+t

Tried CPUFREQ=off but it doesn't help.

[Trenn-novell (trenn-novell)]

> /var/log/messages after SysRq+p and SysRq+t
This was done and is the output when the system was frozen?
On a quick look things look normal.

The currently processed code is some radeon cpu idle routine, so this would point into graphics direction, but as you stated you tried different cards, I doubt it is that (are you sure the other also froze? Better double check if you are unsure).

I am not sure what to look for next, memtest is a good candidate.
If above is the sysrq output of the frozen machine, I am going to ask someone else to have a second look, otherwise I suggest to leave this bug open for a while. Maybe you find out something, then pls let us know, if not this might even be a HW problem or very hard to find because we do not have a single pointer what could cause this yet.

You could try to blacklist the radeon drm module (not sure about the exact name, "lsmod |grep radeon" might show it).
Maybe blacklisting this one helps:
blacklist <module_name>
in /etc/modprobe.conf.local should do that.

[Trenn-novell (trenn-novell)]

No response for quite some time.
You should give 11.1 a try, a lot changed there and got fixed.
If this still happens in 11.1, please reopen the bug.

[Andrea Florio (andrea-opensuse-org)]

Created an attachment (id=318471)
Hardware information

As Summary the installation always freeze on my PC.
It freeze after about 5 minutes and usually freeze on installation summary.

Before report the bug i got 3 freeze

2 at "installation summary"
1 at "customizing boot options"

[Coolo (coolo)]

Are you still able to switch consoles, e.g. alt-ctrl-f2? If so, provide yast logs

[Coolo (coolo)]

I assume media check was successful?

[Andrea Florio (andrea-opensuse-org)]

yes, both md5 and sha1 sum was correct.. i also tried to re-burn the DVD at slower speed and i tried again.

1st time : the machine automatically reboot (about after "new installation/upgrade" screen)

2nd time: installation freeze, keyboard and mouse do not works (i want to check ncurses installation, maybe that's X.org freeze)

3rd time: installation successful

using the same media all the 3 times...

[Andrea Florio (andrea-opensuse-org)]

sorry... one mistake

3rd time: installation freeze in "automatic configuration" after reboot

4th time: installation successful

i think that because the 3rd time froze when it was installed on the pc, y2logs should include freeza data isn't it?

[Coolo (coolo)]

#1 is still unanswered/unprovided

[Andrea Florio (andrea-opensuse-org)]

Created an attachment (id=318995)
y2logs

[Andrea Florio (andrea-opensuse-org)]

it looks to be a X.org failure, even after a succesfull installation (when i freeze i cannot switch to shell) it freeze several times. When it freeze it also reboot sometimes.

i know you dropped (finally from developer side, why so early?? from end-user side) xorg.conf and i'm afraid the problem is there.

in logs you should fine 2 or 3 times so rpms fail installation because after freeze/reboot rpm db was broken, and i had to manually rebuild it.

[Sndirsch (sndirsch)]

For installation we still use fbdev driver - for each and everyone (unless you disabled kernel framebuffer, then you get vesa driver). If the issue also occurs during installation, we would have a general issue in X, since after installation the native driver should be running. More likely is that we see a kernel issue here. In any case please provide /var/log/Xorg.0.log, preferrably without any xorg.conf in place.

[Andrea Florio (andrea-opensuse-org)]

the log hass been already provided: https://bugzilla.novell.com/attachment.cgi?id=318995

[Andrea Florio (andrea-opensuse-org)]

Created an attachment (id=319052)
new logs after a new freeze and reboot

added new logs after a new freeze (and automatic reboot)

no xorg.conf used

[Sndirsch (sndirsch)]

Created an attachment (id=319054)
Xorg.0.log

nv driver running (GeForce 8600 GT). Nothing obvious in the logfile.

[Sndirsch (sndirsch)]

Ok. Please switch to fbdev driver by copying /etc/X11/xorg.conf.install to /etc/X11/xorg.conf (restart Xserver afterwards) to verify if the issue really also occurs with fbdev driver. If it doesn't, nv driver is likely the issue, otherwise we either have a general Xserver issue or it's likely kernel related.
Provide feedback.

[Sndirsch (sndirsch)]

(In reply to comment #10)
> Created an attachment (id=319052) [details]
> new logs after a new freeze and reboot
>
> added new logs after a new freeze (and automatic reboot)
>
> no xorg.conf used

This time you used the proprietary NVIDIA driver. We cannot investigate that issue. Make sure that the freeze occurs with the nv driver. For this uninstall
the proprietary NVIDIA driver.

[Andrea Florio (andrea-opensuse-org)]

the issue actually happend on the following stages:

booting in DVD installation time (fbdev driver ??)

booting from HD (yast2 firstboot automatic config) (nv driver)

running time (nv driver)

running time (nvidia proprietary driver)

i just "cp /etc/X11/xorg.conf.install /etc/X11/xorg.conf" waiting a new freeze

[Andrea Florio (andrea-opensuse-org)]

Created an attachment (id=319080)
xorg logs

Here new logs using xorg.conf.install as "xorg.conf" it froze anyway (i was running yast2 sw_single

[Sndirsch (sndirsch)]

Sounds more like a kernel issue then. Could you attach the lines of /var/log/messages at the time, when such a freeze occurs.

[Andrea Florio (andrea-opensuse-org)]

Created an attachment (id=319085)
/var/log/messages

attached messages log (i added few comments to allow you understand where it freeze

[Andrea Florio (andrea-opensuse-org)]

i forgot to remove "NEEDINFO"

[Sndirsch (sndirsch)]

So nothing obvious in kernel log either. Sorry, no idea what's happening her. I suggest to boot into runlevel 3. If it's occuring also in runlevel 3, it can't be an X related issue.

[Sndirsch (sndirsch)]

Well, of course without X you can't do much and maybe the issue can only be reproduced by running a special X applications although the freeze might not be related to X at all.

I'm afraid we simply can't investigate intermittent freezes, if they aren't obviously related to X or kernel. Thus the resolution for now can only be
WONTFIX.

BTW, I'm also suffering by such freezes since some weeks now on my laptop. Probably X or kernel related, but also without any traces in X or kernel logs.
So you are not alone here.

[Andrea Florio (andrea-opensuse-org)]

Stefan, i still have those freeze with M8, and it looks not to be related to X, since also "init 3" freeze too

[Andrea Florio (andrea-opensuse-org)]

it's definetly a kernel issue, also ubuntu 9.10 with kernel 2.6.31 freeze after few minutes

[Andrea Florio (andrea-opensuse-org)]

I'm an happy linux tester, i don't believe about distro wars, so here i am to report that bug that looks affect kernel 2.6.31 and not openSUSE (my distro) or ubuntu (your distro).

Both, openSUSE 11.2 and Ubuntu 9.10 have kernel 2.6.31 and both freeze after few minutes. This not happen with any other previous version of any distro.

This freeze make me impossible to collect logs informations since i'm not able to complete installation process (the freeze come before installation complete).

you may collect other infos here:

https://bugzilla.novell.com/show_bug.cgi?id=539541

some hardware infos attached

[Andrea Florio (andrea-opensuse-org)]

i reported on ubuntu launchpad too:

https://bugs.launchpad.net/ubuntu/+bug/442194

[Andrea Florio (andrea-opensuse-org)]

i installed 11.1

added lock to kernel-default*
zypper dup to 11.2

booting on 11.2 with kernel-desktop-2.6.31 ---> freeze

booting on 11.2 with kernel-default-2.6.27 (opensuse 11.1 one) ---> perfectly working

[Andrea Florio (andrea-opensuse-org)]

some more infos...

i installed opensuse 11.2 with 2.6.31 kernel plus kernel 2.6.27 (the one shipped with opensuse 11.1 )

result:

kernel 2.6.31 --> freeze

kernel 2.6.27 --> perfectly working

how can i try to do the same with ubuntu?

[Coolo (coolo)]

we need to find out how many machines it may affect. If this is specific to andea's machine, then it's not a ship stopper, but #20 says differently.

[Coolo (coolo)]

ok, there were no other reports against M8, so I don't think it's a ship stopper

[Contezero (contezero)]

I've tested 11.2 RC1 livecd and the problem is not resolved, the system freezes randomly.

[Contezero (contezero)]

I've made some tests with 11.2 and the problem disappear if I disable internal ethernet from BIOS, so the problem should be related to this driver.

[Trenn-novell (trenn-novell)]

Thanks, this helps a lot.
Also that this happens with 11.2, definitely increases priority.

[Trenn-novell (trenn-novell)]

Just for the record, this is a:
K8V-MX (mainboard) ASUS machine.
Chances are high that this boils down to be a BIOS issue.
Check for latest BIOS (eventually there even is a network card firmware upgrade?) and update is probably the first step (Nothing is more annoying than spending a lot time for a bug which already got fixed in BIOS).
If you update the BIOS, please resend acpidump.

[Contezero (contezero)]

There aren't new BIOS version available (latest on asus website is dated 2006/12/15)

[Jeffm-novell (jeffm-novell)]

Do you have another system and/or does your system support a serial console? Setting up a remote console to capture the freeze would be extremely helpful.

[Andrea Florio (andrea-opensuse-org)]

i think so.. how can check and how can i setup this serial remote console?

[Jeffm-novell (jeffm-novell)]

If you're using the serial console, you'll need a null modem cable between the two machines. Then you boot with console=ttyS0,115200 on the node you're testing and run "screen -L /dev/ttyS0 115200" on the other. Change ttyS0 to whatever is appropriate for each node.

Putting it at the end will make it the "primary" console so kernel messages should automatically be directed there. When your system crashes, the messages will be preserved in the screen session on the other machine.

The other option is netconsole, but the modules for that aren't on the install initrd.

[Andrea Florio (andrea-opensuse-org)]

ok guys... good news.
after spending weeks searching the web, i discover the problem is quite strange, but easy to fix.

looks like new kernel changed a bit the way the call acpi(or apic i always forget it). Any way, most of the asus mother board, now hang because of a bios bug that has been fixed by asus it sealf. A bios upgraded is needed to fix this issue.

in particular my mother board:

asus M2N-MX SE PLUS needs bios >= 0503 (latest is 06something)

i think that should be write into RELEASE NOTES.

looks also that disable acpi on boot should be a workaround but i never tought to use it since i never needed it.

[Andrea Florio (andrea-opensuse-org)]

as you can see i wans't the only one to have such freeze:

https://bugzilla.novell.com/show_bug.cgi?id=411797#c34

and again looks to be an asus BIOS problem. one more reason to add this warning into the RELEASE NOTES

[Trenn-novell (trenn-novell)]

I do not expect the message:
<4>ACPI: I/O resource vt596_smbus [0x400-0x407] conflicts with ACPI region SMRG
[0x400-0x40f]
Has anything to do with it -> adjusting title.

What happens is that the IRQs are assigned in a totally other way with 11.0 than with 10.3. Not only via-rhine network card driver also sata IRQs are assigned different. (Here from network card):
(11.0):
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 23 (level, low) -> IRQ 23

pata_via 0000:00:0f.1: version 0.3.3
ACPI: PCI Interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 20

(10.3):
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 23 (level, low) -> IRQ 20

pata_via 0000:00:0f.1: version 0.3.1
ACPI: PCI Interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 16

Strange is that I cannot see any warning/error about it.
Does pci=noacpi bring up the machine as expected?
Maybe acpi_enforce_resources=no helps?

If you still have 10.3, one might also want to attach /proc/interrupts of 10.3 and a newer version. Then we see all the IRQ assignment changes.
I am still puzzled why the IRQ setup is so totally different. Possibly it's really a "modify chipset settings" command like smbus code be used for? Reconfiguring something on the chipset. I fear the only way to find that out could be a git bisect in the end...

[Trenn-novell (trenn-novell)]

In broken case (11.0 dmesg) PATA and SATA via share IRQ 20 (which should
be taken by the network card):

<7>pata_via 0000:00:0f.1: version 0.3.3
<6>ACPI: PCI Interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 20
...
<6>ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 20
<6>sata_via 0000:00:0f.0: routed to hard irq line 10

This:
<6>sata_via 0000:00:0f.0: routed to hard irq line 10
Is what pci config says which IRQ should be taken in hex and this is what is done
on 10.3:

<6>ACPI: PCI Interrupt 0000:00:0f.0[B] -> GSI 20 (level, low) -> IRQ 16
<6>sata_via 0000:00:0f.0: routed to hard irq line 10
...
<7>pata_via 0000:00:0f.1: version 0.3.1
<6>ACPI: PCI Interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 16
<6>scsi2 : pata_via

Hmm, the order of pata_via and sata_via load time is exchanged. Just an idea, but you could try to blacklist pata_via (in /etc/modprobe.conf.local):
blacklist pata_via
-> then run mkinitrd and reboot
to enable it again remove the line from modprobe.conf.local and run mkinitrd again.

[Trenn-novell (trenn-novell)]

Please have a look at the last two comments of bug #539541!
There this is described as an ASUS BIOS problem, which for his machine got fixed in latest BIOS versions.
As in this bug there seem to be several different machines, could everybody please search for the latest BIOS and post whether and which BIOS version fixes this and for which laptop model (and which is unfixable via BIOS update).
Then someone should write this together in the openSUSE wiki into 11.2 FAQ or troubleshooting section or whatever fits best, so that others can google this easily...
Thanks.

PS: I don't want to mark it as a duplicate yet. If it's something else, the mess would be complete...

[Contezero (contezero)]

ASUS haven't updated BIOS for K8V-MX since 2006 and I have last version.
I think the problem is on IRQ assignment as you've explained in commnet 37-38
Actually I cannot do more test on this machine because it's used for some important tasks in the office, and now that I've found a working and stable config (using a PCI network card in place of internal one) I really don't want to make changes.
I think you can mark this as BIOS bug.

[Trenn-novell (trenn-novell)]

> looks like new kernel changed a bit the way
New kernel means this is fixed for you by a 11.2 latest kernel update?
Or did you try the very latest 2.6.33-rcX kernel?

If latest 11.2 update kernel does not fix it, it would be great if you double check kernel-default.rpm and kernel-default-base.rpm from here:
ftp://ftp.suse.com/pub/projects/kernel/kotd/SLE11-SP1

Best use rpm -ivh ... --force --nodeps
boot it once and if you like to you can easily uninstall it again by:
rpm -e kernel-default-${full_version}.rpm kernel-default-base-${full_version}.rpm

Already setting resolved.

[Jeremy Foshee (jeremyfoshee)]

Hi Andrea,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 442194

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]