Bug 137816 - Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet not working in Laptop
Summary: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet not working in Laptop
Status: RESOLVED FIXED
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Alpha 3plus
Hardware: Other Other
: P5 - None : Blocker (vote)
Target Milestone: ---
Assignee: Karsten Keil
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-09 16:09 UTC by Stefan Behlert
Modified: 2005-12-16 13:41 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
lspci (12.22 KB, text/plain)
2005-12-09 16:10 UTC, Stefan Behlert 		Details
/var/log/messages (208.80 KB, text/plain)
2005-12-09 16:12 UTC, Stefan Behlert 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Behlert 2005-12-09 16:09:27 UTC 
This is reproducable for NLD9 sp3, SL10.1alpha3plus and the KOTD 2.6.15-rc5-20051209111139-default:

With all these Releases and the kernels there the internal network of a Maxdata is not working. 
I see lots of
kernel: NETDEV WATCHDOG: eth0: transmit timed out
kernel: eth0: Transmit timeout, status 00000000 00000260 
in /var/log/messages.
"Not working" means, that I don't get any answers from the network. If I start dhcpcd on the interface, I can see requests going out, but the answers are ignored. If I set up the network with static IP and try to ping some hosts I get no answers from those, too.
I have connected an USB-network to the machine, and it is available as g151 with the usual mobile-devices-root-password.
Comment 1 Stefan Behlert 2005-12-09 16:10:42 UTC 
Created attachment 60198 [details]
lspci 

lspci and lspci -vvn
Comment 2 Stefan Behlert 2005-12-09 16:12:08 UTC 
Created attachment 60199 [details]
 /var/log/messages
Comment 3 Olaf Kirch 2005-12-12 10:24:12 UTC 
Thanks Stefan! Karsten, can you look into this?
Comment 4 Karsten Keil 2005-12-12 12:47:18 UTC 
OK seems to be a ACPI related problem, since booting pci=noacpi works fine.
This usually means, that the BIOS has a non conform ACPI IRQ routing table,
and booting pci=noacpi is the only fix we can provide (but this fix has no drawbacks, no performance or feature drop, only a extra entry in /boot/grub/menu.lst).
I'll have a closer look at this tomorrow afternoon.
Comment 5 Stefan Behlert 2005-12-13 11:51:33 UTC 
Strange. I rebooted the machine today and the workaround was no longer working.
Comment 6 Karsten Keil 2005-12-16 13:41:46 UTC 
OK I found a better workaround, boot with option apic  (not acpi!).
This enables the local APIC and so the interrups are routed to more inputs
and zou do not have so much shared IRQs.
This solve sound problems too.
Multiple reboots show that it works reliable for this notebook.