Kernel 2.6.31 freeze the PC
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openSUSE |
Won't Fix
|
Critical
|
|||
linux (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
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:/
some hardware infos attached
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #2 |
Created an attachment (id=229941)
opensuse 11 boot.msg
opensuse 11 boot.msg
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #3 |
Created an attachment (id=229942)
opensuse 10.3 boot.msg
opensuse 10.3 boot.msg
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #4 |
Can you try:
acpi_enforce_
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?
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #5 |
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.
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #6 |
> Can you try:
> acpi_enforce_
> 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.
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #7 |
Created an attachment (id=230661)
hwinfo opensuse 11
hwinfo opensuse 11
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #8 |
Created an attachment (id=230662)
hwinfo opensuse 10.3
hwinfo opensuse 10.3
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #9 |
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.
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #10 |
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.
In Novell/SUSE Bugzilla #411797, Richard-nod (richard-nod) wrote : | #11 |
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
In Novell/SUSE Bugzilla #411797, Richard-nod (richard-nod) wrote : | #12 |
Created an attachment (id=231461)
acpidump
In Novell/SUSE Bugzilla #411797, Richard-nod (richard-nod) wrote : | #13 |
Created an attachment (id=231462)
hwinfo
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #14 |
Puhh, this is hard... there is nothing obvious in dmesg.
Is the temperature controlled by ACPI:
cat /proc/acpi/
or is this dir empty?
If there is something, does this help:
for x in /proc/acpi/
In Novell/SUSE Bugzilla #411797, Richard-nod (richard-nod) wrote : | #15 |
Created an attachment (id=231555)
ls-lR /proc/acpi/
In Novell/SUSE Bugzilla #411797, Richard-nod (richard-nod) wrote : | #16 |
hmm, this does also not help. :-(
/proc/acpi/
sensos says 41°C.
cheers,
//richard
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #17 |
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/
What kind of machine is this?
Is there a newer BIOS available?
In Novell/SUSE Bugzilla #411797, Richard-nod (richard-nod) wrote : | #18 |
this is the output:
--cut--
/proc/acpi/
<setting not supported>
/proc/acpi/
polling frequency: 30 seconds
/proc/acpi/
state: ok
/proc/acpi/
temperature: 60 C
/proc/acpi/
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...
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #19 |
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.
I do not have that mucht time. But as this is rather sever, I try to keep up.
In Novell/SUSE Bugzilla #411797, Richard-nod (richard-nod) wrote : | #20 |
i did a bios update.
now the maschine is DEAD! :-(
maybe i can fix it in a few days...
In Novell/SUSE Bugzilla #411797, Jdelvare (jdelvare) wrote : | #21 |
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_
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:
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.
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #22 |
Created an attachment (id=235229)
acpidump
In Novell/SUSE Bugzilla #411797, Aj-novell (aj-novell) wrote : | #23 |
Information was provided
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #24 |
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.
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #25 |
OK, I've enabled SysRq (cat /proc/sys/
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #26 |
> 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.
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #27 |
> 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?
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #28 |
> 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.
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #29 |
Created an attachment (id=253787)
/var/log/messages after SysRq+p and SysRq+t
Tried CPUFREQ=off but it doesn't help.
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #30 |
> /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.
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #31 |
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.
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #32 |
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"
In Novell/SUSE Bugzilla #539541, Coolo (coolo) wrote : | #33 |
Are you still able to switch consoles, e.g. alt-ctrl-f2? If so, provide yast logs
In Novell/SUSE Bugzilla #539541, Coolo (coolo) wrote : | #34 |
I assume media check was successful?
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #35 |
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/
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...
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #36 |
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?
In Novell/SUSE Bugzilla #539541, Coolo (coolo) wrote : | #37 |
#1 is still unanswered/
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #38 |
Created an attachment (id=318995)
y2logs
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #39 |
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.
In Novell/SUSE Bugzilla #539541, Sndirsch (sndirsch) wrote : | #40 |
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/
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #41 |
the log hass been already provided: https:/
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #42 |
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
In Novell/SUSE Bugzilla #539541, Sndirsch (sndirsch) wrote : | #43 |
Created an attachment (id=319054)
Xorg.0.log
nv driver running (GeForce 8600 GT). Nothing obvious in the logfile.
In Novell/SUSE Bugzilla #539541, Sndirsch (sndirsch) wrote : | #44 |
Ok. Please switch to fbdev driver by copying /etc/X11/
Provide feedback.
In Novell/SUSE Bugzilla #539541, Sndirsch (sndirsch) wrote : | #45 |
(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.
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #46 |
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/
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #47 |
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
In Novell/SUSE Bugzilla #539541, Sndirsch (sndirsch) wrote : | #48 |
Sounds more like a kernel issue then. Could you attach the lines of /var/log/messages at the time, when such a freeze occurs.
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #49 |
Created an attachment (id=319085)
/var/log/messages
attached messages log (i added few comments to allow you understand where it freeze
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #50 |
i forgot to remove "NEEDINFO"
In Novell/SUSE Bugzilla #539541, Sndirsch (sndirsch) wrote : | #51 |
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.
In Novell/SUSE Bugzilla #539541, Sndirsch (sndirsch) wrote : | #52 |
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.
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #53 |
Stefan, i still have those freeze with M8, and it looks not to be related to X, since also "init 3" freeze too
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #54 |
it's definetly a kernel issue, also ubuntu 9.10 with kernel 2.6.31 freeze after few minutes
Andrea Florio (andrea-opensuse-org) wrote : | #55 |
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:/
some hardware infos attached
Andrea Florio (andrea-opensuse-org) wrote : | #56 |
tags: | added: kernel-bug |
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #57 |
i reported on ubuntu launchpad too:
Changed in opensuse: | |
status: | Unknown → Confirmed |
affects: | ubuntu → linux (Ubuntu) |
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #58 |
i installed 11.1
added lock to kernel-default*
zypper dup to 11.2
booting on 11.2 with kernel-
booting on 11.2 with kernel-
Andrea Florio (andrea-opensuse-org) wrote : | #59 |
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?
In Novell/SUSE Bugzilla #539541, Coolo (coolo) wrote : | #60 |
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.
In Novell/SUSE Bugzilla #539541, Coolo (coolo) wrote : | #61 |
ok, there were no other reports against M8, so I don't think it's a ship stopper
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #62 |
I've tested 11.2 RC1 livecd and the problem is not resolved, the system freezes randomly.
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #63 |
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.
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #64 |
Thanks, this helps a lot.
Also that this happens with 11.2, definitely increases priority.
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #65 |
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.
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #66 |
There aren't new BIOS version available (latest on asus website is dated 2006/12/15)
In Novell/SUSE Bugzilla #539541, Jeffm-novell (jeffm-novell) wrote : | #67 |
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.
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #68 |
i think so.. how can check and how can i setup this serial remote console?
In Novell/SUSE Bugzilla #539541, Jeffm-novell (jeffm-novell) wrote : | #69 |
If you're using the serial console, you'll need a null modem cable between the two machines. Then you boot with console=
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.
Changed in opensuse: | |
status: | Confirmed → Incomplete |
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #70 |
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.
In Novell/SUSE Bugzilla #539541, Andrea Florio (andrea-opensuse-org) wrote : | #71 |
as you can see i wans't the only one to have such freeze:
https:/
and again looks to be an asus BIOS problem. one more reason to add this warning into the RELEASE NOTES
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #72 |
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.
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.
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_
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...
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #73 |
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.
blacklist pata_via
-> then run mkinitrd and reboot
to enable it again remove the line from modprobe.conf.local and run mkinitrd again.
In Novell/SUSE Bugzilla #411797, Trenn-novell (trenn-novell) wrote : | #74 |
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...
Changed in opensuse: | |
status: | Incomplete → Confirmed |
In Novell/SUSE Bugzilla #411797, Contezero (contezero) wrote : | #75 |
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.
In Novell/SUSE Bugzilla #539541, Trenn-novell (trenn-novell) wrote : | #76 |
> 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-
ftp://ftp.
Best use rpm -ivh ... --force --nodeps
boot it once and if you like to you can easily uninstall it again by:
rpm -e kernel-
Already setting resolved.
Changed in opensuse: | |
status: | Confirmed → Fix Released |
tags: | added: kj-triage |
Jeremy Foshee (jeremyfoshee) wrote : | #77 |
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://
If it remains an issue, could you run the following command from a Terminal (Applications-
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:/
Thanks in advance.
[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]
tags: | added: needs-kernel-logs |
tags: | added: needs-upstream-testing |
Changed in linux (Ubuntu): | |
status: | New → Incomplete |
Changed in opensuse: | |
importance: | Unknown → Critical |
status: | Fix Released → Won't Fix |
Tried to attach boot.msg but bugzilla give me timeout error.