Bug 137816

Summary:	Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet not working in Laptop
Product:	[openSUSE] SUSE Linux 10.1	Reporter:	Stefan Behlert <behlert>
Component:	Kernel	Assignee:	Karsten Keil <karsten.keil>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Blocker
Priority:	P5 - None
Version:	Alpha 3plus
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	lspci /var/log/messages

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.