Bug 4773 - 8139too requires 'pci=routeirq' - Medion MD9580-F
Summary: 8139too requires 'pci=routeirq' - Medion MD9580-F
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-21 13:25 UTC by Martin W. Kirst
Modified: 2008-03-26 08:40 UTC (History)
10 users (show)

See Also:
Kernel Version: 2.6.11.9, 2.6.11.10, 2.6.11.11, 2.6.12, 2.6.13-rc4
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
hack to test for LNKB vs. LNKA (726 bytes, patch)
2005-08-17 09:56 UTC, Bjorn Helgaas
Details | Diff
dmesg output kernel 2.6.13-rc6 with patch from Bjorn Helgaas 2005-08-17 14:45 (92.80 KB, text/plain)
2005-08-18 00:59 UTC, Johann-Nikolaus Andreae
Details
dmesg output kernel 2.6.13-rc6 with patch from Bjorn Helgaas 2005-08-18 09:42 (10.11 KB, text/plain)
2005-08-18 14:06 UTC, Martin W. Kirst
Details
DSDT from Medion MD9580-F (18.47 KB, application/octet-stream)
2005-08-19 03:09 UTC, Johann-Nikolaus Andreae
Details
patched DSDT from Medion MD9580-F (17.75 KB, application/octet-stream)
2005-08-19 09:00 UTC, Bjorn Helgaas
Details
C-source dsdt2.hex for CONFIG_ACPI_CUSTOM_DSDT (166.75 KB, text/plain)
2005-08-19 09:32 UTC, Bjorn Helgaas
Details
dmesg output kernel 2.6.13-rc6 with patch from Bjorn Helgaas 2005-08-17 14:45 and pacht DSDT (92.63 KB, text/plain)
2005-08-24 06:01 UTC, Johann-Nikolaus Andreae
Details
dmesg output kernel 2.6.13-rc4 with custom DSDT patch from Bjorn Helgaas 2005-08-17 14:45 (11.41 KB, text/plain)
2005-08-31 11:38 UTC, Martin W. Kirst
Details
correct dmesg output kernel 2.6.13 with custom DSDT patch from Bjorn Helgaas 2005-08-17 14:45 (9.81 KB, text/plain)
2005-09-01 12:02 UTC, Martin W. Kirst
Details
dmidecode output Medion MD9580-F (13.66 KB, text/plain)
2007-09-24 02:24 UTC, Johann-Nikolaus Andreae
Details
move 00:09[A] interrupt from LNKA to LNKB (1.69 KB, patch)
2007-12-12 15:55 UTC, Bjorn Helgaas
Details | Diff
quirk debug (791 bytes, patch)
2008-03-24 09:04 UTC, Bjorn Helgaas
Details | Diff
dmesg output with quirk debug patch (14.99 KB, text/plain)
2008-03-25 00:31 UTC, Johann-Nikolaus Andreae
Details
fix medion quirk (839 bytes, patch)
2008-03-25 07:54 UTC, Bjorn Helgaas
Details | Diff
disassembled DSDT (158.18 KB, text/plain)
2008-03-26 08:40 UTC, Bjorn Helgaas
Details

Description Martin W. Kirst 2005-06-21 13:25:20 UTC
Distribution:
 Gentoo Linux 2005.0, Vanilla Kernel
 Bug exists in Kernel: 2.6.12
 Bug exists in Kernel (with acpi-20050408 patch): 2.6.11.9, 2.6.11.10, 2.6.11.11
 Bug _not_ exists in Kernel 2.6.2

Problem Description:
 Kernel module 8139too is succesfull loaded, but no network 
 connections can be established.
 IP settings are manualy applied by ifconfig.
 Error occurs:
 "NETDEV WATCHDOG: eth0: transmit timed out"
 "eth0: Transmit timeout, status 0c 0005 c07f media 10."

Steps to reproduce:
 Load module 8139too and try ping or something else,
 seconds later you can see the problem in 'dmesg'.
 
 Tested with kernel param "acpi=off" something strange
 happend. I've got a connection, but when I have more
 network traffic than with a DSL line the bug
 appears immediately.
 Again, same system with vanilla kernel 2.6.2 works perfect. 

 Any help welcome!

Hardware Environment:
 Laptop, Medion MD9580-F, iP-III (Coppermine), 1GHz, 256MB RAM,
 onboard Realtek 8139c (FIC motherboard, 82371AB/EB/MB PIIX4 ACPI (rev 03))

Software Environment:
$> cat /proc/version
 Linux version 2.6.12 (root@joola.lan.wg) (gcc-Version 3.3.5-20050130
 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1))

$>dmesg |grep -i "8139\|eth"
 8139too Fast Ethernet driver 0.9.27
 eth0: RealTek RTL8139 at 0xd0b0c000, 00:30:54:00:2c:c6, IRQ 10
 eth0:  Identified 8139 chip type 'RTL-8139C'
 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
 NETDEV WATCHDOG: eth0: transmit timed out
 eth0: Transmit timeout, status 0c 0005 c07f media 10.
 eth0: Tx queue start entry 43  dirty entry 39.
 eth0:  Tx descriptor 0 is 0008a042.
 eth0:  Tx descriptor 1 is 0008a042.
 eth0:  Tx descriptor 2 is 0008a042.
 eth0:  Tx descriptor 3 is 0008a042. (queue head) 

$>lspci -vvv
0000:00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RT8139
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Latency: 64 (8000ns min, 16000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at 1c00
	Region 1: Memory at fc001000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Comment 1 Martin W. Kirst 2005-06-23 13:03:00 UTC
Stephen Hemminger <shemminger@osdl.org> wrote:

>> There have been two earlier cases with the same symptoms both because
>> of hardware configuration issues. The newer versions of 8139too driver use
>> NAPI and this exposes interrupt related problems with BIOS config.
>>
>> One was caused because the PCI interrupt was set edge triggered instead of
>> level
>> triggered and that broke NAPI.


There are no settings in my bios setup to set level or edge triggerd.
It seems to be, that my pci devices are level triggered (see dmesg output).
During my investigations I've tested with kernel parameter pci=routeirq.
This works fine right now, no more time outs.  :-) 
So my problem is solved.  :-) 
To me it seems to be most likely that my (cheap) laptop does have
a buggy ACPI setting in BIOS.

So here's my dmesg out:
$> dmesg |grep "ACPI:\|PCI:"
ACPI: RSDP (v000 FIC                                   ) @ 0x000f6bc0
ACPI: RSDT (v001 FIC    ND000030 0x00000001 FIC  0x00000000) @ 0x0fffb152
ACPI: FADT (v001 FIC    ND000030 0x00000001 FACP 0x000f4240) @ 0x0ffffb64
ACPI: BOOT (v001 FIC    ND000030 0x00000001 FIC  0x00000001) @ 0x0ffffbd8
ACPI: DSDT (v001    FIC ND000030 0x00000001 MSFT 0x0100000b) @ 0x00000000
ACPI: setting ELCR to 0200 (from 0020)
PCI: PCI BIOS revision 2.10 entry at 0xfd9ae, last bus=1
PCI: Using configuration type 1
ACPI: Subsystem revision 20050309
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKB] (IRQs 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs *5)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5) *0, disabled.
ACPI: Power Resource [PUSB] (off)
ACPI: Power Resource [PFAN] (on)
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Cannot allocate resource region 4 of device 0000:00:07.1
PCI: Enabling device 0000:00:07.2 (0000 -> 0001)
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ
5
PCI: Enabling device 0000:00:09.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ
10
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ
5
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Thermal Zone [THRM] (48 C)
ACPI: Fan [FAN] (on)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ
10
ACPI: PCI Interrupt 0000:00:0c.1[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ
10


I've tested with parameter "pci=routeirq" and see:
$> dmesg |grep "ACPI:\|PCI:"
ACPI: RSDP (v000 FIC                                   ) @ 0x000f6bc0
ACPI: RSDT (v001 FIC    ND000030 0x00000001 FIC  0x00000000) @ 0x0fffb152
ACPI: FADT (v001 FIC    ND000030 0x00000001 FACP 0x000f4240) @ 0x0ffffb64
ACPI: BOOT (v001 FIC    ND000030 0x00000001 FIC  0x00000001) @ 0x0ffffbd8
ACPI: DSDT (v001    FIC ND000030 0x00000001 MSFT 0x0100000b) @ 0x00000000
ACPI: setting ELCR to 0200 (from 0020)
PCI: PCI BIOS revision 2.10 entry at 0xfd9ae, last bus=1
PCI: Using configuration type 1
ACPI: Subsystem revision 20050309
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKB] (IRQs 10) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs *5)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5) *0, disabled.
ACPI: Power Resource [PUSB] (off)
ACPI: Power Resource [PFAN] (on)
PCI: Using ACPI for IRQ routing
PCI: Routing PCI interrupts for all devices because "pci=routeirq" specified
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ
5
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ
10
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5
ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ
5
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ
10
ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ
10
ACPI: PCI Interrupt 0000:00:0c.1[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ
10
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ
5
PCI: Cannot allocate resource region 4 of device 0000:00:07.1
PCI: Enabling device 0000:00:07.2 (0000 -> 0001)
ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ
5
PCI: Enabling device 0000:00:09.0 (0000 -> 0003)
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ
10
ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ
5
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Thermal Zone [THRM] (45 C)
ACPI: Fan [FAN] (on)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ
10
ACPI: PCI Interrupt 0000:00:0c.1[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ
10


>> The other was cause by another device screwing up
>> see http://www.ussg.iu.edu/hypermail/linux/kernel/0407.0/0954.html

I've had problem while compiling the .c file, which was
posted there. So I couldn't check this.
Comment 2 Hadmut Danisch 2005-06-30 06:39:47 UTC
Hi,

I have a similar problem with my  
  0000:02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd.    
  RTL-8139/8139C/8139C+ (rev 20)

and both the 8139cp and 8139too drivers after moving from 2.6.11.7 to 
2.6.12.2.

After using pci=routeirq the "timed out" messages were gone, but network 
still doesn't work.

Hadmut

 
Comment 3 Andrew Morton 2005-07-28 22:00:15 UTC
Where do we stand with this bug now?  I assume that 2.6.13-rc4
still has problems?

It would help if you could update us on what problems remain -
this report is a little unclear, thanks.
Comment 4 Martin W. Kirst 2005-07-31 06:07:54 UTC
Ok, I will give a little summary, to make this bugreport a little "clearer".
When I created this bugreport I assumed that the problem lies to network
code. After succesfull getting and testing the hint 'pci=routeirq'
I've switched the category to ACPI.

Now I've tested 2.6.13-rc4 without 'pci=routeirq' ...
Result: still timeout problems :-/
dmesg output:
 NETDEV WATCHDOG: eth0: transmit timed out
 eth0: Transmit timeout, status 0d 0004 c07f media 10.
 eth0: Tx queue start entry 4  dirty entry 0.
 eth0:  Tx descriptor 0 is 0008a06e. (queue head)
 eth0:  Tx descriptor 1 is 0008a06e.
 eth0:  Tx descriptor 2 is 0008a06e.
 eth0:  Tx descriptor 3 is 0008a06e.
 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 

Tested 2.6.13-rc4 with 'pci=routeirq',
Result: all seems to be working fine.
Comment 5 Johann-Nikolaus Andreae 2005-08-10 00:51:39 UTC
I have the problem too (also the Medion MD9580-F Notebook).  
I have first observe this bug in kubuntu 5.04 and report it to the ubuntu  
bugzilla http://bugzilla.ubuntu.com/show_bug.cgi?id=9972  
Test with the ubuntu Kernel 2.6.10 and 2.6.11  
The problem ist avalibil in the the SuSE Linux 9.3 Kernel too.  
  
The last working Kernel i have used is the 2.6.8.1 (Gentoo) and 2.6.8-SuSE  
(9.2)  
  
everything i fond out is that the problem is in the recive part.  
if i ping from host1 to host2 i can sniff the echo request an the echo replay  
(from host2) on host2. but the echo request did not can in at host1.  
host1 is the host with the problem.  
  
I will test the 2.6.13-rc4 kernel as sound as possiblit too. 
Comment 6 Len Brown 2005-08-14 23:17:21 UTC
This sure sounds like a driver missing a call
to pci_enable_device().  Do you see this with the
latest version of the 8139too driver?
Comment 7 Johann-Nikolaus Andreae 2005-08-15 02:41:13 UTC
I have testet the kernel 2.6.13-rc6 and the 2.6.13-rc5-git3-3-default from the  
SUSE 10.0 Beta 1  
  
Both work only with acpi=off  
  
Her are the masage with acpi=on: 
 
... 
ACPI: Looking for DSDT in initrd... not found! 
  not found! 
  tbxface-0120 [02] acpi_load_tables        : ACPI Tables successfully 
acquired 
Parsing all Control Methods: ................ 
Table [DSDT](id F004) - 481 Objekts with 42 Devices 115 Methods 18 Regions 
ACPI Namespace succesfully load at root c042e660 
ACPI: setting ELCR to 0200 (from 0020) 
evxfevnt-0096 [03] acpi_enable     : Transition to ACPI mode successful 
NET: Register protocol family 16 
ACPI: bus type pci registered 
PCI: PCI BIOS revision 2.10 entry at 0xfd9ae, last bus=1 
PCI: Using configuration type 1 
ACPI: Subsystem revision 20050408 
evgpeblk-1016 [06] ev_create_gpe_block   : GPE 00 to 0F [_GPE] 2 regs on init 
0x9 
evgpeblk-1024 [06] ev_create_gpe_block   : Found 2 Wake, Enabled 1 Runtime 
GPEs in this block 
Completing Region/Field/Buffer/Package initialisation: ...................... 
Initialized 18/18 Regions 0/0 Fileds 30/30 Buffer 13/17 Packages (490 nodes) 
Execution all Device _STA and _INI methods:.... 
 
Than the system hangs 
Comment 8 Johann-Nikolaus Andreae 2005-08-15 23:37:03 UTC
some additional information get from the 2.6.13-rc6 kernel with ACPI Debug. 
after the output post above follows the following debug output: 
 
[ACPI Debug]    String: [0x22] "-------------------------------------------" 
[ACPI Debug]    String: [0x00] "" 
[ACPI Debug]    String: [0x08] "BAT0_STA" 
[ACPI Debug]    String: [0x22] "---------------" 
 
than the system hangs 
 
hope this help find the bug 
Comment 9 Bjorn Helgaas 2005-08-17 09:56:47 UTC
Created attachment 5658 [details]
hack to test for LNKB vs. LNKA

Martin, with pci=routeirq, I see these additional messages:

ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKB] -> GSI 10 (level, low) ->
IRQ 10

With pci=routeirq, we enable LNKB.  Without it, we don't.  So I wonder
if your 8139 device is really attached to LNKB, not LNKA as your BIOS
claims.  I've had several reports of 8139 breakage, and two (from
D. Stolte and E. Vorster) seem to be the identical FIC BIOS that you
have, so maybe it's just buggy.

Can you try this patch (without pci=routeirq) and see if it forces
the 8139 to use LNKB?
Comment 10 Martin W. Kirst 2005-08-17 11:51:33 UTC
Bjorn, for sure I'will try your patch.

> I've had several reports of 8139 breakage, and two (from
> D. Stolte and E. Vorster) seem to be the identical FIC BIOS
> that you have, so maybe it's just buggy.
This is exactly was I thought, when I realized this bug.
But my knowledge is not as high to prove this  ;-)

I've tested the patch, here are my results.
Used kernel: vanilla-2.6.13-rc4, with patch "hack to test for LNKB vs. LNKA"

$> lspci
 ...
 0000:00:06.0 Communication controller: Ambient Technologies Inc HaM
controllerless modem (rev 02)
 ...
 0000:00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10) 
 ...

Test without 'pci=routeirq':
$> dmesg
 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
 ACPI: PCI Interrupt Link [LNKA] (IRQs 10) *0, disabled.
 ACPI: PCI Interrupt Link [LNKB] (IRQs 10) *0, disabled.
 ACPI: PCI Interrupt Link [LNKC] (IRQs *5)
 ACPI: PCI Interrupt Link [LNKD] (IRQs 5) *0, disabled. 
 ...
 8139too Fast Ethernet driver 0.9.27
 PCI: Enabling device 0000:00:09.0 (0000 -> 0003)
 PCI: setting IRQ 0 as level-triggered
 ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 0 (level, low) -> IRQ 0
 eth0: RealTek RTL8139 at 0xd0814000, 00:30:54:00:2c:c6, IRQ 0
 eth0:  Identified 8139 chip type 'RTL-8139C'

Test with 'pci=routeirq':
$> dmesg
 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
 PCI: setting IRQ 10 as level-triggered
 ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 
 ...
 PCI: setting IRQ 0 as level-triggered
 ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 0 (level, low) -> IRQ 0 
 ...
 8139too Fast Ethernet driver 0.9.27
 PCI: Enabling device 0000:00:09.0 (0000 -> 0003)
 ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 0 (level, low) -> IRQ 0
 eth0: RealTek RTL8139 at 0xd0814000, 00:30:54:00:2c:c6, IRQ 0
 eth0:  Identified 8139 chip type 'RTL-8139C' 
Comment 11 Bjorn Helgaas 2005-08-17 14:45:19 UTC
>  PCI: Enabling device 0000:00:09.0 (0000 -> 0003)
>  PCI: setting IRQ 0 as level-triggered
>  ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 0 (level, low) -> IRQ 0

Oops, sorry, I think I guessed the name of the link wrong.  Can you
try this instead?  If should print out the real full names of all the
links, too, so if it's not "\_SB_.LNKB", we can find out what it is.

Index: work/drivers/acpi/pci_irq.c
===================================================================
--- work.orig/drivers/acpi/pci_irq.c	2005-07-27 13:50:58.000000000 -0600
+++ work/drivers/acpi/pci_irq.c	2005-08-17 14:18:33.000000000 -0600
@@ -124,6 +124,13 @@
 	 *       (e.g. exists somewhere 'below' this _PRT entry in the ACPI
 	 *       namespace).
 	 */
+	if (prt->source[0] &&
+	    entry->id.segment== 0 &&
+	    entry->id.bus == 0 &&
+	    entry->id.device == 9) {
+		acpi_get_handle(handle, "\\_SB_.LNKB", &entry->link.handle);
+		entry->link.index = prt->source_index;
+	} else
 	if (prt->source[0]) {
 		acpi_get_handle(handle, prt->source, &entry->link.handle);
 		entry->link.index = prt->source_index;
@@ -138,10 +145,10 @@
 	else
 		entry->link.index = prt->source_index;
 
-	ACPI_DEBUG_PRINT_RAW((ACPI_DB_INFO,
-		"      %02X:%02X:%02X[%c] -> %s[%d]\n", 
+	printk(
+		"      %04X:%02X:%02X[%c] -> %s[%d]\n", 
 		entry->id.segment, entry->id.bus, entry->id.device, 
-		('A' + entry->pin), prt->source, entry->link.index));
+		('A' + entry->pin), prt->source, entry->link.index);
 
 	spin_lock(&acpi_prt_lock);
 	list_add_tail(&entry->node, &acpi_prt.entries);

Comment 12 Johann-Nikolaus Andreae 2005-08-18 00:59:51 UTC
Created attachment 5664 [details]
dmesg output kernel 2.6.13-rc6 with patch from Bjorn Helgaas 2005-08-17 14:45

this is the dmesg output with the patch
Comment 13 Bjorn Helgaas 2005-08-18 09:42:27 UTC
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=5664&action=view)
> dmesg output kernel 2.6.13-rc6 with patch from Bjorn Helgaas 2005-08-17 14:45

Thanks for the test, Johann-Nikolaus.  Your log confirms that you
have the same BIOS version as the other 8139 problems I've seen:

    ACPI: DSDT (v001    FIC ND000030 0x00000001 MSFT 0x0100000b)

And the patch didn't help anything because the LNKB name was again
wrong (I was just guessing based on the names on an HP DL360, so no
surprise that your link names are different).  It looks like the
correct name for your box is:

    0000:00:09[A] -> \_SB_.PCI0.ISA_.LNKA[0]

Could I trouble you to try the patch below?

Index: work/drivers/acpi/pci_irq.c
===================================================================
--- work.orig/drivers/acpi/pci_irq.c	2005-07-27 13:50:58.000000000 -0600
+++ work/drivers/acpi/pci_irq.c	2005-08-17 14:18:33.000000000 -0600
@@ -124,6 +124,13 @@
 	 *       (e.g. exists somewhere 'below' this _PRT entry in the ACPI
 	 *       namespace).
 	 */
+	if (prt->source[0] &&
+	    entry->id.segment== 0 &&
+	    entry->id.bus == 0 &&
+	    entry->id.device == 9) {
+		acpi_get_handle(handle, "\\_SB_.PCI0.ISA_.LNKB", &entry->link.handle);
+		entry->link.index = prt->source_index;
+	} else
 	if (prt->source[0]) {
 		acpi_get_handle(handle, prt->source, &entry->link.handle);
 		entry->link.index = prt->source_index;
@@ -138,10 +145,10 @@
 	else
 		entry->link.index = prt->source_index;
 
-	ACPI_DEBUG_PRINT_RAW((ACPI_DB_INFO,
-		"      %02X:%02X:%02X[%c] -> %s[%d]\n", 
+	printk(
+		"      %04X:%02X:%02X[%c] -> %s[%d]\n", 
 		entry->id.segment, entry->id.bus, entry->id.device, 
-		('A' + entry->pin), prt->source, entry->link.index));
+		('A' + entry->pin), prt->source, entry->link.index);
 
 	spin_lock(&acpi_prt_lock);
 	list_add_tail(&entry->node, &acpi_prt.entries);

Comment 14 Martin W. Kirst 2005-08-18 14:06:48 UTC
Created attachment 5671 [details]
dmesg output kernel 2.6.13-rc6 with patch from Bjorn Helgaas  2005-08-18 09:42
Comment 15 Bjorn Helgaas 2005-08-18 15:37:11 UTC
OK, I give up.  I still think the 8139 is probably connected to  
LNKB instead of LNKA, but my hack to test that isn't working.  
  
A better way to test this is probably to scrap the patch idea,  
and edit your DSDT.  I've never done this myself, but I'm thinking  
about something like this:  
  
    http://acpi.sourceforge.net/wiki/index.php/HowToOverrideTable  
 
Is this something either of you could try? 
  
Comment 16 Johann-Nikolaus Andreae 2005-08-19 03:09:35 UTC
Created attachment 5676 [details]
DSDT from Medion MD9580-F

I try to to fix the DSDT but I have not any experience with it.
For anybody how has more experience I upload the DSDT
Comment 17 Bjorn Helgaas 2005-08-19 09:00:26 UTC
Created attachment 5688 [details]
patched DSDT from Medion MD9580-F

This is the DSDT uploaded by Johann-Nikolaus, with the following change,
which says PCI device 00:09 uses LNKB instead of LNKA:

--- dsdt.dsl	2005-08-19 09:27:23.000000000 -0600
+++ dsdt2.dsl	2005-08-19 09:30:46.000000000 -0600
@@ -1126,7 +1126,7 @@
		 {
		     0x0009FFFF, 
		     0x00, 
-		     \_SB.PCI0.ISA.LNKA, 
+		     \_SB.PCI0.ISA.LNKB, 
		     0x00
		 }, 
 
To use this, turn on CONFIG_ACPI_CUSTOM_DSDT, point it at a file
containing the new DSDT, and rebuild the kernel.
Comment 18 Bjorn Helgaas 2005-08-19 09:32:14 UTC
Created attachment 5689 [details]
C-source dsdt2.hex for CONFIG_ACPI_CUSTOM_DSDT

Oops, obviously you have to point CONFIG_ACPI_CUSTOM_DSDT_FILE
at something you can compile, i.e., the output of "iasl -tc".
Comment 19 Bjorn Helgaas 2005-08-23 09:53:33 UTC
Martin, Johann-Nikolaus, any chance of trying the custom DSDT? 
If you need help getting that set up, I'd be glad to walk you 
through it. 
Comment 20 Johann-Nikolaus Andreae 2005-08-24 06:01:18 UTC
Created attachment 5745 [details]
dmesg output kernel 2.6.13-rc6 with patch from Bjorn Helgaas 2005-08-17 14:45 and pacht DSDT

sorry for the late answer.
here are the dmesg output
If it helps i upload the output with the pacht from the 2005-08-18 tomorrow
the network is still not working :-(
Comment 21 Bjorn Helgaas 2005-08-24 07:55:28 UTC
> dmesg output kernel 2.6.13-rc6 with patch from Bjorn Helgaas 2005-08-17 14:45
> and pacht DSDT

Sorry, I didn't describe this clearly.  The idea is that you could
use an unpatched kernel (get rid of the pci_irq.c patches I posted
previously), turn on CONFIG_ACPI_CUSTOM_DSDT in your .config, and
point CONFIG_ACPI_CUSTOM_DSDT_FILE at the patched DSDT I uploaded
(http://bugzilla.kernel.org/attachment.cgi?id=5689&action=view).

It'd be nice if ACPI printed a note when overriding the DSDT, but
it doesn't, so I can't tell for sure whether you turned on the
CUSTOM_DSDT stuff.  But it doesn't look like it, because the log
contains:

      0000:00:09[A] -> \_SB_.PCI0.ISA_.LNKA[0]

when the custom DSDT should have

      0000:00:09[A] -> \_SB_.PCI0.ISA_.LNKB[0]

Comment 22 Bjorn Helgaas 2005-08-31 07:58:24 UTC
Is anybody willing to try the test from comment #21? 
Comment 23 Martin W. Kirst 2005-08-31 11:38:33 UTC
Created attachment 5833 [details]
dmesg output kernel 2.6.13-rc4 with custom DSDT patch from Bjorn Helgaas 2005-08-17 14:45

Sorry for the late answer.
I'm currently writing my diploma master thesis.
So I do not have much spare time :-/

By the way, I've installed a fresh windows xp on this laptop
and the eth0 doesn't work either. So were do I switch on
the kernel parameter 'routeirq=pci' in windows? *justkidding* :-)
But, in real, are theses dsdt patches portable?
Comment 24 Bjorn Helgaas 2005-08-31 14:35:47 UTC
> Sorry for the late answer.
> I'm currently writing my diploma master thesis.
> So I do not have much spare time :-/

No problem, I just don't want to completely drop this bug
report.

And I'm sorry that I don't seem to be able to communicate the
test I'd like done.  Both you and Johann-Nikolaus tested a
patch I posted that is known not to work.

The test I would *like* someone to try is to use a completely
unpatched kernel, such as vanilla 2.6.13.  Build it with the
CONFIG_ACPI_CUSTOM_DSDT option turned on and set the CUSTOM_DSDT_FILE
to the patched DSDT (attachment 5689 [details]).

> By the way, I've installed a fresh windows xp on this laptop
> and the eth0 doesn't work either. So were do I switch on
> the kernel parameter 'routeirq=pci' in windows? *justkidding* :-)

Very interesting.  Another indication that the real problem
is a BIOS bug.

We currently don't have a "quirks" model for ACPI, so even if
we confirm a BIOS bug, it's not clear how we can work around
it in Linux.  I was hoping to eventually remove "pci=routeirq",
but possibly we'll have to keep it around for situations like
this.

> But, in real, are theses dsdt patches portable?

No, in fact, the patched DSDT is *not* portable.  Your machine
seems very close to Johann-Nikolaus's, though, so the one I
patched for him may work for you.  If you attach your DSDT,
I'll disassemble it and patch yours, too.

Comment 25 Martin W. Kirst 2005-09-01 02:34:53 UTC
@ Bjorn,
It seems that I have something missconfigured yesterday.

I need a little more help.
This is, was I made till now:
1. wget linux-2.6.13.tar.bz2 (vanilla)
2. tar -xvjf ...
3. cp ../oldconfig .
4. make oldconfig (no errors)
5. first "strange thing": I didn't find CONFIG_ACPI_CUSTOM_DSDT
   in my .config, so 
6. appended two lines to my .config
   CONFIG_ACPI_CUSTOM_DSDT=y
   CONFIG_ACPI_CUSTOM_DSDT_FILE="/usr/src/patch.h"
7. make bzImage; make modules; make modules_install (no errors)
8. reopen .config -> my previously added lines are gone ?!

So, what do I have to do, that the kernel kompiles correctly
with this settings?
   

Comment 26 Bjorn Helgaas 2005-09-01 07:52:29 UTC
> I need a little more help.
> This is, was I made till now:
> 1. wget linux-2.6.13.tar.bz2 (vanilla)
> 2. tar -xvjf ...
> 3. cp ../oldconfig .
> 4. make oldconfig (no errors)

The above all looks good.

> 5. first "strange thing": I didn't find CONFIG_ACPI_CUSTOM_DSDT
>    in my .config, so 

CONFIG_ACPI_CUSTOM_DSDT depends on !STANDALONE.  Do a
"make menuconfig", go to "Device Drivers"/"Generic Driver
Options", and set CONFIG_STANDALONE=n (the menu text is
"Select only drivers that don't need compile-time external
firmware".

Then if you return to "Power management and ACPI"/"ACPI",
the "Include Custom DSDT" option should be selectable.
If you set it to "y", you should then be able to specify
the "Custom DSDT Table file to include".  Make sure the
file you specify contains the C source.  It looks like
this:

    unsigned char AmlCode[] = 
    {
        0x44,0x53,0x44,0x54,0x02,0x47,0x00,0x00,  /* 00000000    "DSDT.G.." */
    ...

That should be it.  It should build a kernel that you can
just boot normally.  And we're particularly interested in
whether eth0 works without having to specify "pci=routeirq".

Thanks!

Comment 27 Bjorn Helgaas 2005-09-01 08:00:50 UTC
> By the way, I've installed a fresh windows xp on this laptop     
> and the eth0 doesn't work either. So were do I switch on     
> the kernel parameter 'routeirq=pci' in windows? *justkidding* :-)     
     
It occurred to me that there *might* be a workaround that will     
get eth0 working under Windows XP.  The theory is that the eth0    
device (00:09.0) is on LNKB, but the BIOS reports it on LNKA.   
   
Linux doesn't enable LNKB because the BIOS says it's only used by   
00:06.0, the "Ambient Technologies Inc HaM controllerless modem", 
and Linux doesn't seem to have a driver for that device. 
 
So if you can find and install a Windows driver for that modem, the 
driver should enable LNKB (perhaps only if the modem is in use), 
and then eth0 should work. 
Comment 28 Martin W. Kirst 2005-09-01 12:02:52 UTC
Created attachment 5852 [details]
correct dmesg output kernel 2.6.13 with custom DSDT patch from Bjorn Helgaas 2005-08-17 14:45

I've followed your suggestions with maximum success :-)
Even if no routeirq=pci specified, the ethernet works perfect.

I've made an attachment with the correct dmesg out.
Comment 29 Martin W. Kirst 2005-09-01 12:13:28 UTC
@Bjorn,

>Linux doesn't enable LNKB because the BIOS says it's only used by   
>00:06.0, the "Ambient Technologies Inc HaM controllerless modem", 
>and Linux doesn't seem to have a driver for that device. 
>So if you can find and install a Windows driver for that modem, the 
>driver should enable LNKB (perhaps only if the modem is in use), 
>and then eth0 should work. 

Luckyly there was no problem to get a (little outdated) driver
for this "creatix v.90 ham data fax modem" for Windows.

And you are right, it works. :-)

Thanks man, you saved my ass :-)
Comment 30 Bjorn Helgaas 2005-09-01 14:40:37 UTC
On Thursday 01 September 2005 1:03 pm, bugme-daemon@kernel-bugs.osdl.org wrote:
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=5852&action=view)
> correct dmesg output kernel 2.6.13 with custom DSDT patch from Bjorn Helgaas
> 2005-08-17 14:45
> 
> I've followed your suggestions with maximum success :-)
> Even if no routeirq=pci specified, the ethernet works perfect.

Great, glad to hear it!  Thanks for persevering with this.
And good that we also have a Windows workaround.

Unfortunately, I don't have any ideas about how to easily work
around this for Linux.  I don't suppose there's any chance
of Medion updating the BIOS?  I think we have pretty convincing
evidence of exactly what the defect is.  And the fact that it
also hurts on Windows should help.

I looked into uploading the patched DSDT here:

    http://acpi.sourceforge.net/dsdt/index.php

But I couldn't figure out how to create a new user (the user
link gives a 404 error).

Comment 31 Bjorn Helgaas 2005-09-01 14:47:03 UTC
Hi Hadmut,

Do you have any updated status on this problem?

    http://bugzilla.kernel.org/show_bug.cgi?id=4773

We found that Martin's problem was a Medion BIOS bug.  And
I'm 99% sure that Johann-Nikolaus's is seeing the same BIOS
ug.

But I suspect that your issue might be different, because
your 8139 is at a different PCI address, so you probably
have a completely different machine and BIOS.

If you are still seeing the problem, and you do have a
different machine, can you please open a new bugzilla
for it?  Please attach the complete dmesg and output
of "lspci -vv".

Since "pci=routeirq" didn't solve the problem for you,
you might also cc: the 8139 driver maintainer
(Jeff Garzik <jgarzik@pobox.com>).

Thanks!

Comment 32 Hadmut Danisch 2005-09-04 08:00:31 UTC
Hi,

sorry for the delay, I was pretty busy.


Bjorn Helgaas wrote:
> Hi Hadmut,
> 
> Do you have any updated status on this problem?
> 
>     http://bugzilla.kernel.org/show_bug.cgi?id=4773
> 

To be honest, I had completely forgotten this bug, since
it worked again with some later kernel. I am not sure at the moment
whether I left the pci=routeirq in the command line or not, it's my
office notebook.

However, there were also problems with the wireless card. These turned
out to be problems because of a buggy bios table.

regards
Hadmut

Comment 33 Ulrich Holeschak 2005-10-26 23:08:14 UTC
I have also problem with the 8139too since kernel 2.6.13. in Kernel 2.6.11 all
was perfect. But in my case ACPI is DISABLED (and not compiled into the kernel)
so this seems to be a different problem.
I have already tried with different PCI slots and interrupts but nothing helps.

There is no IO-APIC on this board only an XT-PIC.
The chipset is VIA82CXXX.

This is what the syslog shows
Oct 23 18:38:39 router kernel: NETDEV WATCHDOG: eth2: transmit timed out
Oct 23 18:38:39 router kernel: eth2: Transmit timeout, status 01 0000 0000 media 10.
Oct 23 18:38:39 router kernel: eth2: Tx queue start entry 4  dirty entry 0.
Oct 23 18:38:39 router kernel: eth2:  Tx descriptor 0 is 00002000. (queue head)
Oct 23 18:38:39 router kernel: eth2:  Tx descriptor 1 is 00002000.
Oct 23 18:38:39 router kernel: eth2:  Tx descriptor 2 is 00002000.
Oct 23 18:38:39 router kernel: eth2:  Tx descriptor 3 is 00002000.
Oct 23 18:38:39 router kernel: eth2: link up, 100Mbps, full-duplex, lpa 0x41E1
Oct 23 18:38:39 router kernel: eth2: Promiscuous mode enabled.
Comment 34 Bjorn Helgaas 2005-10-27 08:40:50 UTC
> I have also problem with the 8139too since kernel 2.6.13. in Kernel 2.6.11
> all
> was perfect. But in my case ACPI is DISABLED (and not compiled into the
> kernel)
> so this seems to be a different problem.
> I have already tried with different PCI slots and interrupts but nothing
> helps.
> 
> There is no IO-APIC on this board only an XT-PIC.
> The chipset is VIA82CXXX.

Thanks for the report!  Since you're not using ACPI, this is
indeed a different issue.  Can I trouble you to open a new
defect report?  Please include a complete dmesg log and the
contents of /proc/interrupts.

If you can also include a dmesg log and /proc/interrupts for
2.6.11, where it works fine, the differences between the
2.6.11 and 2.6.13 logs may have a clue.
Comment 35 schaedpq 2006-01-13 02:23:03 UTC
I would like to add my experiences with this issue as I also own the Medion
MD9580-F and had the very same problem (using 2.6.11 and 2.6.14) The problem
drove me crazy for days until I stumbled over this bugzilla entry. Thank you for
the work being done here. :-)
Distribution: Gentoo 2005.1, Kernels 2.6.11-hardened, 2.6.14-hardened and
2.6.14-gentoo

I think I have a thing to add: On my machine eth0 works again, if I append
acpi=off but while receiving large files the connection stalls after every few
megabytes for some time (30-60s), after that the data transfer is resumed and I
have again a "NETDEV WATCHDOG: eth0: transmit timed out" in my kernel log:
Jan 13 11:02:55 phoenix NETDEV WATCHDOG: eth0: transmit timed out
Jan 13 11:02:55 phoenix eth0: Transmit timeout, status 0c 0055 c07f media 10.
Jan 13 11:02:55 phoenix eth0: Tx queue start entry 471  dirty entry 467.
Jan 13 11:02:55 phoenix eth0:  Tx descriptor 0 is 0008a03c.
Jan 13 11:02:55 phoenix eth0:  Tx descriptor 1 is 0008a03c.
Jan 13 11:02:55 phoenix eth0:  Tx descriptor 2 is 0008a053.
Jan 13 11:02:55 phoenix eth0:  Tx descriptor 3 is 0008a03c. (queue head)
Jan 13 11:02:55 phoenix eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

While using pic=routeirq everything works fine, without any interruptions during
data transfers.
I did not patch my DSDT until now, but hopefully I will do that today.
I you would like to see any logs from my system please tell me and I will attach
them then.
Comment 36 Len Brown 2007-08-18 20:43:08 UTC
Name (_PRT, Package (0x0B) {
 Package (0x04) { 0x0001FFFF, 0x00, \_SB.PCI0.ISA.LNKC, 0x00 },
 Package (0x04) { 0x0004FFFF, 0x00, \_SB.PCI0.ISA.LNKC, 0x00 },
 Package (0x04) { 0x0006FFFF, 0x00, \_SB.PCI0.ISA.LNKB, 0x00 },
 Package (0x04) { 0x0007FFFF, 0x00, \_SB.PCI0.ISA.LNKA, 0x00 },
 Package (0x04) { 0x0007FFFF, 0x01, \_SB.PCI0.ISA.LNKB, 0x00 },
 Package (0x04) { 0x0007FFFF, 0x02, \_SB.PCI0.ISA.LNKC, 0x00 },
 Package (0x04) { 0x0007FFFF, 0x03, \_SB.PCI0.ISA.LNKD, 0x00 },
 Package (0x04) { 0x0009FFFF, 0x00, \_SB.PCI0.ISA.LNKA, 0x00 },

## Yep, the DSDT shows that 0000:00:09.0[A] (should be) on LNKA

 Package (0x04) { 0x000CFFFF, 0x00, \_SB.PCI0.ISA.LNKA, 0x00 },
 Package (0x04) { 0x000CFFFF, 0x01, \_SB.PCI0.ISA.LNKB, 0x00 },
 Package (0x04) { 0x000DFFFF, 0x00, \_SB.PCI0.ISA.LNKA, 0x00 } })

ACPI: PCI Interrupt Link [LNKA] (IRQs 10) *0, disabled.

## though it is sort of unexpected that LNKA should come to Linux
   from the BIOS in a disabled state -- assuming that
   the devices on it are enabled in the BIOS.

But yes, the fact that enabling LNKB w/o pci=routeirq sure makes
this looks like a plain 'ol BIOS bug; and the fact that the
same failure is seen on Windows until the modem driver is
loaded confirms that.  It also confirms that Linux is bug compatible
with Windows:-)

Perhaps we should simply automatically enable pci=routeirq
for BIOS that matches this one?  Anybody care to provide dmidecode output?
Comment 37 Martin W. Kirst 2007-08-20 11:23:34 UTC
(In reply to comment #36)

> [...] Anybody care to provide dmidecode output?
> 

Yes, I could. But could you please give me some little more keywords
what to do. So next Time when I own this laptop I can do this.
Comment 38 Len Brown 2007-08-20 12:02:29 UTC
If you own this laptop, please boot Linux on it with "pci=routeirq"
to work around its BIOS bug.

So that we can enhance Linux automatically recognize the bug in this laptop
and invoke "pci=routeirq" automatically for you, please attach the
output from dmidecode to this bug report.  If dmidecode is not present
on your system, you can get it from the source:

http://www.nongnu.org/dmidecode/
Comment 39 Fu Michael 2007-09-23 01:35:34 UTC
ping for bug reporters: could you please attach dmidecode output? thanks!
Comment 40 Martin W. Kirst 2007-09-23 07:04:29 UTC
(In reply to comment #39)
> ping for bug reporters: could you please attach dmidecode output? thanks!
> 

Ping-Reply ;-)
Sorry for long waiting, I will get this laptop in one week, so after
next weekend, I will present results.
Comment 41 Johann-Nikolaus Andreae 2007-09-24 02:24:10 UTC
Created attachment 12914 [details]
dmidecode output Medion MD9580-F

Here is the dmidecode output.
Comment 42 Natalie Protasevich 2007-12-11 22:23:27 UTC
Does everyone confirm that Bjorn's workaround works for them? - Then the bug can be resolved/closed.
Thanks.
Comment 43 schaedpq 2007-12-12 02:12:58 UTC
Bjorn's workaround was patching the DSDT and using this user supplied one in the kernel? Uh, yes, as far as I remember that worked on my machine. But for using that workaround the user has to be fairly experienced and find this bug first... And in case of live CDs (Knoppix, rescue systems, distributions and such) it may be a rather painful route to go.
Of course, these machines are already quite old and maybe it isn't worth the effort to implement some automatically enabled fix (on affected machines) in the kernel.
Comment 44 Bjorn Helgaas 2007-12-12 15:55:40 UTC
Created attachment 14003 [details]
move 00:09[A] interrupt from LNKA to LNKB

The manual workaround is to use "pci=routeirq" or to load a driver for the "creatix v.90 ham data fax modem".

It would be much better to fix Linux to detect and work around the problem automatically.  This patch is a first try.  If somebody can test it and verify that it works, we can argue about whether this is a reasonable approach.
Comment 45 Bjorn Helgaas 2008-01-03 11:05:29 UTC
Can someone please test the patch in comment #44, report the results, and attach the dmesg log?  Thanks!
Comment 46 schaedpq 2008-01-03 11:30:33 UTC
I used pci=routeirq with success for most of the time I owned the machine and the new owner told me, that it still works with a current ubuntu distribution and kernel, but I have to ask him about the exact kernel version and dmesg log.
Comment 47 Johann-Nikolaus Andreae 2008-01-05 01:22:40 UTC
I i am still use this notebock
I test the pacht in february, current i have no time.
Comment 48 Zhang Rui 2008-03-17 01:45:58 UTC
Please make sure the patch in comment #44 can fix the problem for you.
Or else I'll close this bug.
Comment 49 Johann-Nikolaus Andreae 2008-03-19 23:30:29 UTC
Now i have test the patch in comment #44 it fix the problem.
Comment 50 Zhang Rui 2008-03-20 00:24:10 UTC
Patch in comment #44 fixes the bug.
Bjorn,
for this patch and the patch in bug#5044 comment#33,
do you think they should go upstream?
Comment 51 Bjorn Helgaas 2008-03-20 09:42:25 UTC
A newer version of this patch is already upstream:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=391df5dce30a5aab477b9e55ea65a3e83bae96b1

Johann-Nikolaus, I don't know if you'll have a chance to try the upstream kernel, but if you notice that it doesn't work, please let me know.
Comment 52 Johann-Nikolaus Andreae 2008-03-22 07:45:51 UTC
I test the upstream. It did not work.
I miss the output from the patch in the log.
Comment 53 Bjorn Helgaas 2008-03-24 09:04:20 UTC
Created attachment 15414 [details]
quirk debug

Hmmm..., I'm sorry it didn't work.  I checked the DMI signature and the DSDT names again, and it looks right, but maybe I got the full LNK name wrong.  Can you try again with this debugging patch?  Please attach the complete dmesg output.
Comment 54 Johann-Nikolaus Andreae 2008-03-25 00:31:33 UTC
Created attachment 15423 [details]
dmesg output with quirk debug patch

So here are the dmesg output.
Comment 55 Bjorn Helgaas 2008-03-25 07:54:29 UTC
Created attachment 15426 [details]
fix medion quirk

Oh, I see the problem.  Apparently we pad every pathname component out to four characters.  Can you try this patch?  If you confirm that it works, I'll try to get it in for 2.6.25.
Comment 56 Johann-Nikolaus Andreae 2008-03-25 08:35:12 UTC
Now i works for me.
Thanks for the Patch.
Comment 57 Len Brown 2008-03-25 17:34:25 UTC
patch in comment #55 applied to acpi tree
Comment 58 Len Brown 2008-03-26 08:35:51 UTC
linux simultaneously picked up path in comment #55

b97d4803400a4442b0e4ae14d0bd8e83994b9004
ACPI: fix Medion _PRT quirk (use "ISA_", not "ISA")

which shipped in 2.6.25-rc7

closed
Comment 59 Bjorn Helgaas 2008-03-26 08:40:24 UTC
Created attachment 15448 [details]
disassembled DSDT

Note You need to log in before you can comment on or make changes to this bug.