|
Bugzilla – Full Text Bug Listing |
| Summary: | ACPI broken on Fujitsu Simens Amilo A1645: Network, sound and some others problems | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Gianluigi Pulcio <pulciux> |
| Component: | Mobile Devices | Assignee: | Vojtech Pavlik <vojtech> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | felix, vojtech |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | SuSE Linux 10.0 | ||
| Whiteboard: | |||
| Found By: | Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
dmesg with acpi=off in boot parameters
dmesg without acpi=off in boot parameters interrupts when is acpi=off in boot parameters interrupts when is not acpi=off in boot parameters syslog acpi with log level 19 |
||
|
Description
Gianluigi Pulcio
2005-11-05 08:29:49 UTC
Thomas, could this have something to do with ec_burst? I have tried to start installation with ec_burst=1 at boot time but nothing is changed. In syslog the same rows are present and NIC won't work. After some others tests with boot options, I have tried with acpi=off and all work fine eccept, of curse, powersafe. In syslog i read: Nov 8 07:37:08 linux [powersave]: ERROR (CPUFreq_Kernel:23) Try CPUFREQ_CONTROL=userspace in /etc/sysconfig/powersave/cpufreq. Nov 8 07:37:08 linux [powersave]: ERROR (PM_Interface:231) Cannot create cpufreq objects Try ec_burst=0, ec_burst=1 is default. Hmm, could you better try pci=noacpi, please. I have tried first with ec_burst=0 then with pci=noacpi and also with both but nothing is changed. Only with acpi=off is working but powersave. First, please make sure you have the latest BIOS installed on your machine. If it still does not work, please attach full dmesg and /proc/interrupts output of both, with and without acpi=off. Created attachment 57267 [details]
dmesg with acpi=off in boot parameters
Created attachment 57269 [details]
dmesg without acpi=off in boot parameters
Created attachment 57270 [details]
interrupts when is acpi=off in boot parameters
Created attachment 57271 [details]
interrupts when is not acpi=off in boot parameters
I've looked for bios version and it was the newer. No update possible. So I have attached to the bug the requested 4 outputs. Hmm interrupts are assigned in the same way for acpi=off and without. Vojtech, you have much more experience with this stuff than me... and touchpad is also loosing ticks/interrupts? Do I interpret this right, that some ACPI code probably is too long in irq_disabled context and therefore network, touchpad and possibly other interrupts are not serviced? If yes, how can we find this part? There is a known problem with powernow_k8 and cpufreq_ondemand. Can you remove cpufreq_ondemand and see whether the problem persists? Similarly I'd suggest removing the 'battery' and 'thermal' ACPI modules to check whether one of them may be causing the problems. Also, using 'report_lost_ticks=1' on the kernel command line it might be possible to see where the time is spent. I made many tests and now I'm becoming little confused. I have disabled one for time the modules. First "cpufreq_ondemand", then "battery" and again "thermal". Problem was still present. So I have disabled all acpi'modules, removed "fan" "processor" and "thermal" from initrd. Nothing. Only when is acpi=off or is acpi=oldboot the problem is not present. Using "report_lost_ticks=1" on boot no new information is generated. So i searched for "report_lost_ticks=1" and I found it in time.c for x86_64. But this is a AMD Sempron and not seem to be a 64bit processor. But with acpi started in dmesg is present this: powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.50.3) powernow-k8: 0 : fid 0xc (2000 MHz), vid 0xa (1300 mV) powernow-k8: 1 : fid 0xa (1800 MHz), vid 0xc (1250 mV) powernow-k8: 2 : fid 0x8 (1600 MHz), vid 0xe (1200 mV) powernow-k8: 3 : fid 0x0 (800 MHz), vid 0x13 (1075 mV) With acpi=off in dmesg is: powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.50.3) powernow-k8: BIOS error: maxvid exceeded with pstate 0 powernow: This module only works with AMD K7 CPUs I've setted the log level of acpi to 19 (1+2+16) and I attach the output from syslog. Created attachment 57804 [details]
syslog acpi with log level 19
I am having the same problem with a maxdata notebook. (At the moment i am not able to get the exact product name.) The sis900 problem seems to be kernel related, as I found the following report: http://bugzilla.kernel.org/show_bug.cgi?id=5065 The maxdate has a severe sound-problem too, after logging in to KDE you can hear the first second of the startupsound over and over. I will report more detailed as soon as I have access to the notebook. What information could be helpfull? Looking through bugzilla I found the follwing entry: https://bugzilla.novell.com/show_bug.cgi?id=135498 I think it is a duplicate of this bug. Today I have access to the machine again, therfore i tried to collect some more information: I get the following in my dmesg: hs01@hs01:~> grep eth /tmp/dmesg eth0: SiS 900 PCI Fast Ethernet at 0xd800, IRQ 5, 00:03:0d:3b:91:75. eth0: Media Link Off eth0: no IPv6 routers present eth0: Media Link On 100mbps full-duplex NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 00000004 00000249 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 00000004 00000249 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 00000000 00000279 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 00000000 00000260 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 00000000 00000260 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 00000000 00000260 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 00000000 00000260 NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timeout, status 00000000 00000260 The network card is: 00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 91) The machine in question is a "MAXDATA NB ECO 4000 A" more information can be found at http://partnernet.maxdata.co.uk/download/entry_index.htm The biggest problem seems to be the network: I will add werner@suse.de to cc: as he seems to be responsible for network. My Fujitsu Siemens Amilo A1645 is a AMD Sempron, but 3300+, not 2600+. The cipset is the same (sis M760), nic also (sis900). Graphics card is a sis660 and audio is a AC'97 sis. For comment #18: I'm only the QA for network which means I reassign the bugs to the appropiate maintainers and/or wizards. But for this IMHO broken hardware I do not know any wizard. Won't be fixed with 10.0, I assume. Is testing this notebook with the latest OpenSUSE.org 10.1 beta possible? (In reply to comment #21) > Won't be fixed with 10.0, I assume. > Is testing this notebook with the latest OpenSUSE.org 10.1 beta possible? > I will try as shortly as possible and then I'll report to bugzilla. (In reply to comment #21) > Won't be fixed with 10.0, I assume. > Is testing this notebook with the latest OpenSUSE.org 10.1 beta possible? > I've tested 10.1 beta 4 on my amilo A1645 but the problems are still present. Same as on suse OSS 10.0. If needed I can post some logs. (In reply to comment #21) > Won't be fixed with 10.0, I assume. > Is testing this notebook with the latest OpenSUSE.org 10.1 beta possible? I just downloaded 10.1 beta5. If everything goes well I should have access to the "MAXDATA NB ECO 4000 A" by tomorrow (26.2.) arround noon. I will check on the sound and on the network problem. Looking at http://bugzilla.kernel.org/show_bug.cgi?id=5065#c7 the network problem might be fixed. What information do you want me to provide? The default installation of SuSE 10.1 beta5 is working without problems on my machine. The sis900 problem is gone and the sound problem is not there anymore too. I can provide the dmesg and lspci output if needed. (In reply to comment #21) > Won't be fixed with 10.0, I assume. > Is testing this notebook with the latest OpenSUSE.org 10.1 beta possible? > I have tried my amilo A1645 with 10.1 beta 5 and the problem is gone. NIC is working, ACPI also and then sound card. I think that the bug is fixed. Wonderful. Closing. |