Bug 4773
|
Description
Martin W. Kirst
2005-06-21 13:25:20 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. 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 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. 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. 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. 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? 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 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 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?
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'
> 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);
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
> --> (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);
Created attachment 5671 [details]
dmesg output kernel 2.6.13-rc6 with patch from Bjorn Helgaas 2005-08-18 09:42
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?
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
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.
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".
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. 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 :-(
> 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] Is anybody willing to try the test from comment #21? 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?
> 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. @ 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? > 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! > 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.
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.
@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 :-)
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). 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!
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
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. > 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.
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. 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?
(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. 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/ ping for bug reporters: could you please attach dmidecode output? thanks! (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. Created attachment 12914 [details]
dmidecode output Medion MD9580-F
Here is the dmidecode output.
Does everyone confirm that Bjorn's workaround works for them? - Then the bug can be resolved/closed. Thanks. 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. 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.
Can someone please test the patch in comment #44, report the results, and attach the dmesg log? Thanks! 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. I i am still use this notebock I test the pacht in february, current i have no time. Please make sure the patch in comment #44 can fix the problem for you. Or else I'll close this bug. Now i have test the patch in comment #44 it fix the problem. 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? 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. I test the upstream. It did not work. I miss the output from the patch in the log. 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.
Created attachment 15423 [details]
dmesg output with quirk debug patch
So here are the dmesg output.
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.
Now i works for me. Thanks for the Patch. patch in comment #55 applied to acpi tree 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 Created attachment 15448 [details]
disassembled DSDT
|